<div dir="ltr">> <span style="font-size:12.8px">Are we better off using branches instead of cmove to implement FP to</span><br style="font-size:12.8px"><span style="font-size:12.8px">unsigned i64?</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This seems like it was done for perf reason (mispredict). Conditional-to-cmov transformation should keep from introducing additional observable side-effects, and it's clear that whatever did this did not account for floating point exception.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 19, 2017 at 10:01 AM, Michael Clark 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 style="word-wrap:break-word"><div>Changing the list from cfe-dev to llvm-dev</div><div><div class="h5"><br><div><blockquote type="cite"><div>On 20 Apr 2017, at 4:52 AM, Michael Clark <<a href="mailto:michaeljclark@mac.com" target="_blank">michaeljclark@mac.com</a>> wrote:</div><br class="m_-1919249784359824534Apple-interchange-newline"><div><div style="word-wrap:break-word"><div>I’m getting close. I think it may be an issue with an individual intrinsic. I’m looking for the X86 lowering of Instruction::FPToUI.</div><div><br></div><div>I found a comment around the rationale for using a conditional move versus a branch. I believe the predicate logic using a conditional move is causing INEXACT to be set from the other side of the predicate as the lowered x86_64 code executes both conversions whereas GCC uses a branch. That seems to be the difference.</div><div><br></div><div>I can’t find FPToUI in llvm/lib/Target/X86 so I’m trying to figure out what the cast gets renamed to in the target layer so I can find where the sequence is emitted.</div><div><br></div><div><br></div><div>$ more llvm/lib/Target/X86//README-<wbr>X86-64.txt</div><div>…</div><div>Are we better off using branches instead of cmove to implement FP to<br>unsigned i64?<br><br>_conv:<br> ucomiss LC0(%rip), %xmm0<br> cvttss2siq %xmm0, %rdx<br> jb L3<br> subss LC0(%rip), %xmm0<br> movabsq $-9223372036854775808, %rax<br> cvttss2siq %xmm0, %rdx<br> xorq %rax, %rdx<br>L3:<br> movq %rdx, %rax<br> ret<br><br>instead of<br><br>_conv:<br> movss LCPI1_0(%rip), %xmm1<br> cvttss2siq %xmm0, %rcx<br> movaps %xmm0, %xmm2<br> subss %xmm1, %xmm2<br> cvttss2siq %xmm2, %rax<br> movabsq $-9223372036854775808, %rdx<br> xorq %rdx, %rax<br> ucomiss %xmm1, %xmm0<br> cmovb %rcx, %rax<br> ret<br><br></div><br><div><blockquote type="cite"><div>On 19 Apr 2017, at 2:10 PM, Michael Clark <<a href="mailto:michaeljclark@mac.com" target="_blank">michaeljclark@mac.com</a>> wrote:</div><br class="m_-1919249784359824534Apple-interchange-newline"><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On 19 Apr 2017, at 1:14 PM, Tim Northover <<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>> wrote:</div><br class="m_-1919249784359824534Apple-interchange-newline"><div><div>On 18 April 2017 at 15:54, Michael Clark via cfe-dev<br><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br><blockquote type="cite">The only way towards completing a milestone is via fixing a number of small issues along<br>the way…<br></blockquote><br>I believe there's more to it than that. None of LLVM's optimizations<br>are aware of this extra side-channel of information (with possible<br>exceptions like avoiding speculating fdiv because of unavoidable<br>exceptions).<br><br>From what I remember, the real proposal is to replace all<br>floating-point IR with intrinsics when FENV_ACCESS is on, which the<br>optimizers by default won't have a clue about and will treat<br>conservatively (essentially like they're modifying external memory).<br><br>So be careful with drawing conclusions from small snippets; you're<br>probably not seeing the full range of LLVM's behaviour.<br></div></div></blockquote></div><br><div><br></div><div><div>Yes. I’m sure.</div><div><br></div><div>It reproduces with just the cast on its own: <a href="https://godbolt.org/g/myUoL2" target="_blank">https://godbolt.org/g/<wbr>myUoL2</a></div><div><br></div><div>It appears to be in the LLVM lowering of the fptoui intrinsic so it must MC layer optimisations.</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="Courier">; Function Attrs: noinline nounwind uwtable</font></div><div><font face="Courier">define i64 @_Z7fcvt_luf(float %f) #0 {</font></div><div><font face="Courier"> %1 = alloca float, align 4</font></div><div><font face="Courier"> store float %f, float* %1, align 4</font></div><div><font face="Courier"> %2 = load float, float* %1, align 4</font></div><div><font face="Courier"> %3 = fptoui float %2 to i64</font></div><div><font face="Courier"> ret i64 %3</font></div><div><font face="Courier">}</font></div></blockquote><div><br></div><div>GCC performs a comparison with ucomiss and branches whereas Clang computes both forms and predicates the result using a conditional move. One of the conversions obviously is setting the INEXACT MXCSR flag.</div><div><br></div><div>Clang lowering (inexact set when result is exact):</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><font face="Courier">fcvt_lu(float):<br> movss xmm1, dword ptr [rip + .LCPI1_0] # xmm1 = mem[0],zero,zero,zero<br> movaps xmm2, xmm0<br> subss xmm2, xmm1<br> cvttss2si rax, xmm2<br> movabs rcx, -9223372036854775808<br> xor rcx, rax<br> cvttss2si rax, xmm0<br> ucomiss xmm0, xmm1<br> cmovae rax, rcx<br> ret</font></blockquote><div><br></div><div>GCC lowering (sets flags correctly):</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><font face="Courier">fcvt_lu(float):<br> ucomiss xmm0, DWORD PTR .LC0[rip]<br> jnb .L4<br> cvttss2si rax, xmm0<br> ret<br>.L4:<br> subss xmm0, DWORD PTR .LC0[rip]<br> movabs rdx, -9223372036854775808<br> cvttss2si rax, xmm0<br> xor rax, rdx<br> ret</font></blockquote></div></div></div></blockquote></div><br></div></div></blockquote></div><br></div></div></div><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></blockquote></div><br></div>