[llvm-dev] Is this undefined behavior optimization legal?

[Mehdi Amini via llvm-dev]

> On Oct 3, 2016, at 1:51 PM, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi,
> 
> I've found a test case where SelectionDAG is doing an undefined behavior
> optimization, and I need help determining whether or not this is legal.
> 
> Here is the example IR: 
> 
> define void @test(<4 x i8> addrspace(1)* %out, float %a) {
>  %uint8 = fptoui float %a to i8
>  %vec = insertelement <4 x i8> <i8 0, i8 0, i8 0, i8 0>, i8 %uint8, i32 0
>  store <4 x i8> %vec, <4 x i8> addrspace(1)* %out
>  ret void
> }
> 
> Since %vec is a 32-bit vector, a common way to implement this function on a target
> with 32-bit registers would be to zero initialize a 32-bit register to hold
> the initial vector and then 'mask' and 'or' the inserted value with the
> initial vector.  In AMDGPU assembly it would look something like:
> 
> v_mov_b32 v0, 0
> v_cvt_u32_f32_e32 v1, s0
> v_and_b32 v1, v1, 0x000000ff
> v_or_b32 v0, v0, v1
> 
> The optimization the SelectionDAG does for us in this function, though, ends
> up removing the mask operation.  Which gives us:
> 
> v_mov_b32 v0, 0
> v_cvt_u32_f32_e32 v1, s0
> v_or_b32 v0, v0, v1
> 
> The reason the SelectionDAG is doing this is because it knows that the result
> of %uint8 = fptoui float %a to i8 is undefined when the result uses more than
> 8-bits.  So, it assumes that the result will only set the low 8-bits, because
> anything else would be undefined behavior and the program would be broken.
> This assumption is what causes it to remove the 'and' operation.
> 
> So effectively, what has happened here, is that by inserting the result of
> an operation with undefined behavior into one lane of a vector, we have
> overwritten all the other lanes of the vector.
> 
> Is this optimization legal?  To me it seems wrong that undefined behavior
> in one lane of a vector could affect another lane.  

Isn’t undefined behavior in a program that all the program is undefined?
I’m not sure why you think that there should be a limit to what the optimizer can do specifically on the vector lane while we don’t put any limit usually.

There might be a question about your fptoui conversion here though: is it guarantee to write zero to the upper bits of the 32bits register?
In the IR it produces an i8 value, and insert it in a vector. It isn’t clear to me which combine / transformation knows that the fptoui will zero the upper part of the register.

— 
Mehdi



> However, given that LLVM IR
> is SSA and we are technically creating a new vector and not modifying the old
> one, then maybe it's OK.  I'm just not sure.
> 
> Appreciate any insight people may have.
> 
> Thanks,
> Tom
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev