<div dir="ltr">Setting aside any correctness or other concerns, it seems a waste for a frontend to have to change the width of the integer at all, and it would seem really easy for LLVM to not care about the width of the integer at all.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 26, 2014 at 8:09 PM, Michael Spencer <span dir="ltr"><<a href="mailto:bigcheesegs@gmail.com" target="_blank">bigcheesegs@gmail.com</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">On Sat, Apr 26, 2014 at 7:55 PM, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br>

><br>
> On Apr 25, 2014, at 7:17 PM, Michael Spencer <<a href="mailto:bigcheesegs@gmail.com">bigcheesegs@gmail.com</a>> wrote:<br>
><br>
>> Given the following C code llvm currently generates suboptimal code for<br>
>> x86-64:<br>
>><br>
>> __m128 bss4( const __m128 *ptr, size_t i, size_t j )<br>
>> {<br>
>>    float f = ptr[i][j];<br>
>>    return (__m128) { f, f, f, f };<br>
>> }<br>
>><br>
>> =================================================<br>
>><br>
>> define <4 x float> @_Z4bss4PKDv4_fmm(<4 x float>* nocapture readonly %ptr, i64 %i, i64 %j) #0 {<br>
>>  %a1 = getelementptr inbounds <4 x float>* %ptr, i64 %i<br>
>>  %a2 = load <4 x float>* %a1, align 16, !tbaa !1<br>
>>  %a3 = trunc i64 %j to i32<br>
>>  %a4 = extractelement <4 x float> %a2, i32 %a3<br>
>>  %a5 = insertelement <4 x float> undef, float %a4, i32 0<br>
>>  %a6 = insertelement <4 x float> %a5, float %a4, i32 1<br>
>>  %a7 = insertelement <4 x float> %a6, float %a4, i32 2<br>
>>  %a8 = insertelement <4 x float> %a7, float %a4, i32 3<br>
>>  ret <4 x float> %a8<br>
>> }<br>
>><br>
>> =================================================<br>
>><br>
>>        shlq    $4, %rsi<br>
>>        addq    %rdi, %rsi<br>
>>        movslq  %edx, %rax<br>
>>        vbroadcastss    (%rsi,%rax,4), %xmm0<br>
>>        retq<br>
>><br>
>> =================================================<br>
>><br>
>> The movslq is uneeded, but is present because of the trunc to i32 and then<br>
>> sext back to i64 that the backend adds for vbroadcastss.<br>
>><br>
>> We can't remove it because it changes the meaning.<br>
><br>
> How does it change meaning?  Only the low 2 bits of the index are meaningful, if any of the other ones are set, you get an undefined result.<br>
><br>
> -Chris<br>
<br>
</div></div>if %j has any bits > 32 set to 1, the trunc removes them. At the<br>
IR/SDag level we don't know why the trunc is there (the intent may be<br>
to mask out the top bits), so we can't remove it.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Michael Spencer<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>