Union handling of ifelse

[nalimilan]

In the following example, SIMD is enabled when x is of the element type of A (here Int8), but not when it is of a different type (e.g. Int). I imagine this can be due to overflow checks, but the compiler should ideally be able to check this before entering the loop. This also happens when x is hardcoded as a constant inside the function body instead of being passed as an argument, in which case the check could happen statically.

julia> using BenchmarkTools

julia> function test!(A::AbstractArray, x)
           @inbounds for i in eachindex(A)
               Ai = A[i]
               A[i] = ifelse(Ai == 1, Ai, x)
           end
           A
       end
test! (generic function with 1 method)

julia> A = rand(Int8, 10_000);

julia> @btime test!(A, 100);
  77.495 μs (0 allocations: 0 bytes)

julia> @btime test!(A, Int8(100));
  208.595 ns (0 allocations: 0 bytes)

[yuyichao]

The overflow check isn't causing any problem. With the ifelse replaced with branch, the inlining is still not agressive enough for the setindex! though.

[vtjnash]

but not when it is of a different type

In general, you should probably stick to using actual conditionals (?:), ifelse is likely to continue to always play second-fiddle. #25934 will probably help, but after Keno's PR, I strongly suspect we should just delete this intrinsic and define it simply as ifelse(b, x, y) = b ? x : y.

[vchuravy]

I would prefer not deleting `ifelse` it's semantics make it important in GPU code and for SIMD usage (although in both contexts it is more likely to be called `select`)

…

On Tue, Feb 20, 2018, 20:41 Jameson Nash ***@***.***> wrote: but not when it is of a different type In general, you should probably stick to using actual conditionals (?:), ifelse is likely to continue to always play second-fiddle. #25934 <#25934> will probably help, but after Keno's PR, I strongly suspect we should just delete this intrinsic and define it simply as ifelse(b, x, y) = b ? x : y. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#26134 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAI3alBm1EvHhEPqr0Pm4McdcB5im8JNks5tW3Q9gaJpZM4SMupS> .

[yuyichao]

Is LLVM not smart enough?

[quinnj]

@vtjnash, but are there cases where LLVM wouldn't change ?: to select, but a user might want to force it explicitly for cases like SIMD?

[yuyichao]

Note that I believe the hardest (and sometimes impossible) thing for the compiler to prove is that it is safe/beneficial for the two cases be eagerly evaluated. As long as it's clear to LLVM that it's a branch that has no sideeffect, I think it should be pretty trivial for it to do the transformation and any cases where it fails to do so will probably be a LLVM bug that shouldn't be too hard to fix. (edit: in another word, my "Is LLVM not smart enough?" was a serious question about the state of the GPU backend).

It's worth noting that the eager evaluation semantics is actually not provided by select but by the fact that ifelse is a function and not syntax. In another word, I don't think we should remove the function API (i.e. ifelse) but the lower level intrinsics can probably be removed.