<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 21 Apr 2017, at 8:50 AM, Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" class="">andrew.kaylor@intel.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9.5pt;" class="">> This seems like it was done for perf reason (mispredict). Conditional-to-cmov transformation should keep<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9.5pt;" class="">> from introducing additional observable side-effects, and it's clear that whatever did this did not account<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9.5pt;" class="">> for floating point exception.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><a name="_MailEndCompose" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">That’s a very reasonable statement, but I’m not sure it corresponds to the way we have typically approached this sort of problem.</span></a></div></div></div></blockquote><div><br class=""></div><div>Just out of interest, I ran the two code sequences (branch vs predicate logic) through Intel Architecture Code Analyzer:</div><div><br class=""></div><div>- <a href="https://gist.github.com/michaeljclark/84f9e411ab959073996e10bff6ab8ec0" class="">https://gist.github.com/michaeljclark/84f9e411ab959073996e10bff6ab8ec0</a></div><div><br class=""></div><div>I am not sure how accurate the cycle estimate is for the GCC code sequence as it says “possibly". It would appear that if the branch is predicted in a loop of floating point values that are < LLONG_MAX then GCC would win. Some values > LLONG_MAX and some <= LLONG_MAX would fool the branch predictor.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">In particular, there has been a de facto standard practice (and it has even been openly stated and agreed upon once or twice) of assuming default rounding mode and ignoring FP exceptions in the default (and currently only) optimization path for FP-related instructions. That is, clang/LLVM didn’t just not support FENV_ACCESS by indifference but rather we have made conscious decisions to allow transformations that violate the needs of FENV_ACCESS when doing so can improve the performance of generated code. Basically, we more or less pretend that floating point status bits don’t exist (at least before you get to the target-specific backend).</span></div></div></div></blockquote><div><br class=""></div><div>It is a shame as Clang/LLVM does surprisingly well at honouring floating point accrued exceptions on x86_64 as is (see below).</div><div><br class=""></div><div>As far as I can tell, besides the eager constant folding optimisation, the only issues I am facing is with the float to u64 and double to u64 intrinsics.</div><div><br class=""></div><div>I have expressed the RISC-V floating point ISA in a C notation, which I use to build a RISC-V ISA simulator, and the floating point accrued exceptions are tested for the complete set of RISC-V FPU operations. I’ve been using the RISC-V ISA test suite essentially to test gcc and clang floating point accrued exception state and the test suite has relatively complete accrued exception state tests after any floating point operations that update the accrued exception state. Clang does very well, with the exception of float to u64 and double to u64. They are currently the only two operations that fail the RISC-V QEMU tests, which is essentially testing all of the compiler floating point intrinsics.</div><div><br class=""></div><a href="https://github.com/michaeljclark/riscv-meta/blob/ea306062bfd2f60a229daf6b04826cdeb2dfbe9d/meta/opcode-pseudocode-c#L132-L204" class="">https://github.com/michaeljclark/riscv-meta/blob/ea306062bfd2f60a229daf6b04826cdeb2dfbe9d/meta/opcode-pseudocode-c#L132-L204</a></div><div><br class=""></div><div>These are the tests that I am using to exercise clang and gcc FENV_ACCESS along with the C code in the link above. riscv-qemu-tests is a user-mode port of the RISC-V ISA conformance test suite.</div><div><br class=""></div><div>- <a href="https://github.com/arsv/riscv-qemu-tests/tree/master/rv64f" class="">https://github.com/arsv/riscv-qemu-tests/tree/master/rv64f</a></div><div>- <a href="https://github.com/arsv/riscv-qemu-tests/tree/master/rv64d" class="">https://github.com/arsv/riscv-qemu-tests/tree/master/rv64d</a></div><div><br class=""></div><div>The tests are not exhaustive. There are some special cases with rounding modes that are not tested and the code is isolated from certain optimisations and is essentially testing just the intrinsics. That said, it makes sense for the intrinsics to correctly set the floating point accrued exception state to allow any more complete handling of optimisation around floating point operations.</div><div><br class=""></div><div><div>In any case I need these conversions to work on compilers today so I came up with this work-around:</div><div><br class=""></div><div>- <a href="https://godbolt.org/g/Ez8RZA" class="">https://godbolt.org/g/Ez8RZA</a></div><div class=""><br class=""></div><div class=""><div>With the workaround above I am able to pass all of the RISC-V tests, however I know of some corner cases that are not tested. Interestingly float and double to unsigned need to round or clamp negative values to zero. I guess this is undefined behaviour in C.</div></div><div class=""><br class=""></div></div><div><blockquote type="cite" class=""><div class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">You’ll find that the X86 backend doesn’t even model MXCSR at the moment. I tried to add it recently and it kind of blew up before I had even modeled it for anything other than LDMXCSR and STMCXSR. We may want to address that at some point, but right now it just isn’t there.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">When we discussed how FENV_ACCESS support should be implemented, Chandler proposed that when restricted modes (whether FENV_ACCESS or any other front end-specific analogous behavior) were not being used the optimizer should be able to behave as described above and that nothing done to support restricted FP behavior should complicate or restrict the default optimizer behavior. This was met with general agreement at the time.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">I mention all this as prologue to saying that while we should do something to get FPToUI lowered without incorrectly setting FP exception status bits, it isn’t necessarily what we want as the default behavior.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">I would also like to add that I personally am very pleased that you discovered this issue and have gotten as far as you have in the analysis of the problem. I’m in the process of adding constrained versions of various FP intrinsics (I have a patch ready to be sent out today) and what I’ve done up to now has been to simply translate the constrained operations into their traditional representations somewhere in the ISel process. I was aware that something would need to be done in the codegen space to continue protecting these operations, but I was kind of hoping that the actual instruction selection would be reasonably safe. FWIW, FPToUI is not one of the parts my pending patch addresses.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class="">-Andy<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><a name="_____replyseparator" class=""></a><b class=""><span style="font-size: 11pt; font-family: Calibri, sans-serif;" class="">From:</span></b><span style="font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="Apple-converted-space"> </span>llvm-dev [<a href="mailto:llvm-dev-bounces@lists.llvm.org" class="">mailto:llvm-dev-bounces@lists.llvm.org</a>]<span class="Apple-converted-space"> </span><b class="">On Behalf Of<span class="Apple-converted-space"> </span></b>Flamedoge via llvm-dev<br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>Wednesday, April 19, 2017 10:14 AM<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Michael Clark <<a href="mailto:michaeljclark@mac.com" class="">michaeljclark@mac.com</a>><br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span>llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>><br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [llvm-dev] [cfe-dev] FE_INEXACT being set for an exact conversion from float to unsigned long long<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">> <span style="font-size: 9.5pt;" class="">Are we better off using branches instead of cmove to implement FP to<br class="">unsigned i64?</span><o:p class=""></o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 9.5pt;" class="">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><o:p class=""></o:p></div></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">On Wed, Apr 19, 2017 at 10:01 AM, Michael Clark via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" style="color: purple; text-decoration: underline;" class="">llvm-dev@lists.llvm.org</a>> wrote:<o:p class=""></o:p></div><blockquote style="border-style: none none none solid; border-left-width: 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;" class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">Changing the list from cfe-dev to llvm-dev<o:p class=""></o:p></div></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">On 20 Apr 2017, at 4:52 AM, Michael Clark <<a href="mailto:michaeljclark@mac.com" target="_blank" style="color: purple; text-decoration: underline;" class="">michaeljclark@mac.com</a>> wrote:<o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">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.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">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.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">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.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">$ more llvm/lib/Target/X86//README-X86-64.txt<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">…<o:p class=""></o:p></div></div><div class=""><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 12pt; font-family: 'Times New Roman', serif;">Are we better off using branches instead of cmove to implement FP to<br class="">unsigned i64?<br class=""><br class="">_conv:<br class=""> ucomiss LC0(%rip), %xmm0<br class=""> cvttss2siq %xmm0, %rdx<br class=""> jb L3<br class=""> subss LC0(%rip), %xmm0<br class=""> movabsq $-9223372036854775808, %rax<br class=""> cvttss2siq %xmm0, %rdx<br class=""> xorq %rax, %rdx<br class="">L3:<br class=""> movq %rdx, %rax<br class=""> ret<br class=""><br class="">instead of<br class=""><br class="">_conv:<br class=""> movss LCPI1_0(%rip), %xmm1<br class=""> cvttss2siq %xmm0, %rcx<br class=""> movaps %xmm0, %xmm2<br class=""> subss %xmm1, %xmm2<br class=""> cvttss2siq %xmm2, %rax<br class=""> movabsq $-9223372036854775808, %rdx<br class=""> xorq %rdx, %rax<br class=""> ucomiss %xmm1, %xmm0<br class=""> cmovb %rcx, %rax<br class=""> ret<o:p class=""></o:p></p></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">On 19 Apr 2017, at 2:10 PM, Michael Clark <<a href="mailto:michaeljclark@mac.com" target="_blank" style="color: purple; text-decoration: underline;" class="">michaeljclark@mac.com</a>> wrote:<o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">On 19 Apr 2017, at 1:14 PM, Tim Northover <<a href="mailto:t.p.northover@gmail.com" target="_blank" style="color: purple; text-decoration: underline;" class="">t.p.northover@gmail.com</a>> wrote:<o:p class=""></o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">On 18 April 2017 at 15:54, Michael Clark via cfe-dev<br class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" style="color: purple; text-decoration: underline;" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""><br class=""><o:p class=""></o:p></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">The only way towards completing a milestone is via fixing a number of small issues along<br class="">the way…<o:p class=""></o:p></div></blockquote><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><br class="">I believe there's more to it than that. None of LLVM's optimizations<br class="">are aware of this extra side-channel of information (with possible<br class="">exceptions like avoiding speculating fdiv because of unavoidable<br class="">exceptions).<br class=""><br class="">From what I remember, the real proposal is to replace all<br class="">floating-point IR with intrinsics when FENV_ACCESS is on, which the<br class="">optimizers by default won't have a clue about and will treat<br class="">conservatively (essentially like they're modifying external memory).<br class=""><br class="">So be careful with drawing conclusions from small snippets; you're<br class="">probably not seeing the full range of LLVM's behaviour.<o:p class=""></o:p></div></div></div></blockquote></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">Yes. I’m sure.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">It reproduces with just the cast on its own: <a href="https://godbolt.org/g/myUoL2" target="_blank" style="color: purple; text-decoration: underline;" class="">https://godbolt.org/g/myUoL2</a><o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">It appears to be in the LLVM lowering of the fptoui intrinsic so it must MC layer optimisations.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><blockquote style="margin-left: 30pt; margin-right: 0in;" class=""><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-family: Courier;" class="">; Function Attrs: noinline nounwind uwtable</span><o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-family: Courier;" class="">define i64 @_Z7fcvt_luf(float %f) #0 {</span><o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-family: Courier;" class=""> %1 = alloca float, align 4</span><o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-family: Courier;" class=""> store float %f, float* %1, align 4</span><o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-family: Courier;" class=""> %2 = load float, float* %1, align 4</span><o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-family: Courier;" class=""> %3 = fptoui float %2 to i64</span><o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-family: Courier;" class=""> ret i64 %3</span><o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-family: Courier;" class="">}</span><o:p class=""></o:p></div></div></blockquote><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">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.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">Clang lowering (inexact set when result is exact):<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><blockquote style="margin-left: 30pt; margin-right: 0in;" class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-family: Courier;" class="">fcvt_lu(float):<br class=""> movss xmm1, dword ptr [rip + .LCPI1_0] # xmm1 = mem[0],zero,zero,zero<br class=""> movaps xmm2, xmm0<br class=""> subss xmm2, xmm1<br class=""> cvttss2si rax, xmm2<br class=""> movabs rcx, -9223372036854775808<br class=""> xor rcx, rax<br class=""> cvttss2si rax, xmm0<br class=""> ucomiss xmm0, xmm1<br class=""> cmovae rax, rcx<br class=""> ret</span><o:p class=""></o:p></div></blockquote><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">GCC lowering (sets flags correctly):<o:p class=""></o:p></div></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div><blockquote style="margin-left: 30pt; margin-right: 0in;" class=""><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-family: Courier;" class="">fcvt_lu(float):<br class=""> ucomiss xmm0, DWORD PTR .LC0[rip]<br class=""> jnb .L4<br class=""> cvttss2si rax, xmm0<br class=""> ret<br class="">.L4:<br class=""> subss xmm0, DWORD PTR .LC0[rip]<br class=""> movabs rdx, -9223372036854775808<br class=""> cvttss2si rax, xmm0<br class=""> xor rax, rdx<br class=""> ret</span><o:p class=""></o:p></div></blockquote></div></div></div></blockquote></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div></div></blockquote></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div></div></div></div><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><br class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" style="color: purple; text-decoration: underline;" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" style="color: purple; text-decoration: underline;" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></p></blockquote></div></div></div></div></blockquote></div><br class=""></body></html>