<div dir="ltr">> <span style="font-size:12.8px">This assumption is what causes it to remove the 'and' operation.<br><br>CMIIW, this assumption appears to be flawed. Initialization values are escaping side-effects and removing them is making a correct program incorrect.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">-Kevin</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 3, 2016 at 2:27 PM, Mehdi Amini via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> On Oct 3, 2016, at 1:51 PM, Tom Stellard via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> I've found a test case where SelectionDAG is doing an undefined behavior<br>
> optimization, and I need help determining whether or not this is legal.<br>
><br>
> Here is the example IR:<br>
><br>
> define void @test(<4 x i8> addrspace(1)* %out, float %a) {<br>
>  %uint8 = fptoui float %a to i8<br>
>  %vec = insertelement <4 x i8> <i8 0, i8 0, i8 0, i8 0>, i8 %uint8, i32 0<br>
>  store <4 x i8> %vec, <4 x i8> addrspace(1)* %out<br>
>  ret void<br>
> }<br>
><br>
> Since %vec is a 32-bit vector, a common way to implement this function on a target<br>
> with 32-bit registers would be to zero initialize a 32-bit register to hold<br>
> the initial vector and then 'mask' and 'or' the inserted value with the<br>
> initial vector.  In AMDGPU assembly it would look something like:<br>
><br>
> v_mov_b32 v0, 0<br>
> v_cvt_u32_f32_e32 v1, s0<br>
> v_and_b32 v1, v1, 0x000000ff<br>
> v_or_b32 v0, v0, v1<br>
><br>
> The optimization the SelectionDAG does for us in this function, though, ends<br>
> up removing the mask operation.  Which gives us:<br>
><br>
> v_mov_b32 v0, 0<br>
> v_cvt_u32_f32_e32 v1, s0<br>
> v_or_b32 v0, v0, v1<br>
><br>
> The reason the SelectionDAG is doing this is because it knows that the result<br>
> of %uint8 = fptoui float %a to i8 is undefined when the result uses more than<br>
> 8-bits.  So, it assumes that the result will only set the low 8-bits, because<br>
> anything else would be undefined behavior and the program would be broken.<br>
> This assumption is what causes it to remove the 'and' operation.<br>
><br>
> So effectively, what has happened here, is that by inserting the result of<br>
> an operation with undefined behavior into one lane of a vector, we have<br>
> overwritten all the other lanes of the vector.<br>
><br>
> Is this optimization legal?  To me it seems wrong that undefined behavior<br>
> in one lane of a vector could affect another lane.<br>
<br>
</div></div>Isn’t undefined behavior in a program that all the program is undefined?<br>
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.<br>
<br>
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?<br>
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.<br>
<br>
—<br>
Mehdi<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> However, given that LLVM IR<br>
> is SSA and we are technically creating a new vector and not modifying the old<br>
> one, then maybe it's OK.  I'm just not sure.<br>
><br>
> Appreciate any insight people may have.<br>
><br>
> Thanks,<br>
> Tom<br>
> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>