Reducing estimated cost of not_int to zero for more reasonable inlining

[kimikage]

Surprisingly(?), there is a non-trivial difference between the two functions below:

f(x) = x == zero(x) ? "zero" : "non-zero"

g(x) = x != zero(x) ? "non-zero" : "zero"

The estimated cost of g(x::Int) is 1 higher than f(x::Int) due to the extra Base.not_int.

julia/base/compiler/tfuncs.jl

Line 146 in f2fa6cf

add_tfunc(not_int, 1, 1, math_tfunc, 1)

Although you might think the difference is trivial, this can cause speed differences of ~10 times depending on the SIMD vectorization. (For example, JuliaGraphics/Colors.jl#407)

As you know, the cost model of inlining has room for improvement, and the modeling is "extremely" difficult. However my suggestion is just to change one character on the line shown above.

I think we seldom use Base.not_int(::Int64), and often use Base.not_int(::Bool). It is usually required in conditional expressions, and in most CPU instruction sets there are instructions or special operands for negative conditions (e.g. "not equal", "not less than"). Therefore, IMO, the cost 0 is reasonable.

[StefanKarpinski]

Makes sense: negating a condition basically never increases the instruction count.