Hi, I met troubles with jitting x86 codes when using Intrinsic::x86_sse_ldmxcsr. The target code must execute some SSE2 instruction with DAZ/FTZ modes enabled and others with DAZ/FTZ disabled. I'm trying to get this by emitting LDMXCSR instructions with proper flag words. It appeared however that execution engine sometimes reorders these instructions with computational ones (say with Intrinsic::x86_sse2_min_pd as we have in the scenario). As a result, wrong floating point values are produced. The issue disappears when using llvm::CodeGenOpt::None instead of Default, but of course this is too big hammer for using as a workaround. Is it a bug, or am I missing some smart settings to prohibit reordering? Regards, Mikhail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140128/40725ac0/attachment.html>
Hi Mikhail, At the moment we don’t model MXCSR. We don’t even have explicit dependencies between IR floating point instructions and the instructions that set the rounding mode (like MXCSR), so arithmetic instructions are likely to be moved across calls that change the rounding mode. You can work around this problem by setting artificial barriers, such as placing your arithmetic calculations in external functions that can’t be inlined, etc. Thanks, Nadav On Jan 27, 2014, at 4:03 PM, Mikhail Lyapunov <mikhaill at microsoft.com> wrote:> Hi, > > I met troubles with jitting x86 codes when using Intrinsic::x86_sse_ldmxcsr. > The target code must execute some SSE2 instruction with DAZ/FTZ modes enabled and others with DAZ/FTZ disabled. > I’m trying to get this by emitting LDMXCSR instructions with proper flag words. > It appeared however that execution engine sometimes reorders these instructions with computational ones (say with Intrinsic::x86_sse2_min_pd as we have in the scenario). > As a result, wrong floating point values are produced. > > The issue disappears when using llvm::CodeGenOpt::None instead of Default, but of course this is too big hammer for using as a workaround. > > Is it a bug, or am I missing some smart settings to prohibit reordering? > > Regards, > Mikhail > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140127/a966d1a7/attachment.html>
Thanks the for comprehensive reply. Hopefully the issue will be addressed some time later. Thanks, Mikhail From: Nadav Rotem [mailto:nrotem at apple.com] Sent: Monday, January 27, 2014 4:11 PM To: Mikhail Lyapunov Cc: <llvmdev at cs.uiuc.edu>; Yuri Dotsenko Subject: Re: [LLVMdev] ldmxcsr reordering issue Hi Mikhail, At the moment we don't model MXCSR. We don't even have explicit dependencies between IR floating point instructions and the instructions that set the rounding mode (like MXCSR), so arithmetic instructions are likely to be moved across calls that change the rounding mode. You can work around this problem by setting artificial barriers, such as placing your arithmetic calculations in external functions that can't be inlined, etc. Thanks, Nadav On Jan 27, 2014, at 4:03 PM, Mikhail Lyapunov <mikhaill at microsoft.com<mailto:mikhaill at microsoft.com>> wrote: Hi, I met troubles with jitting x86 codes when using Intrinsic::x86_sse_ldmxcsr. The target code must execute some SSE2 instruction with DAZ/FTZ modes enabled and others with DAZ/FTZ disabled. I'm trying to get this by emitting LDMXCSR instructions with proper flag words. It appeared however that execution engine sometimes reorders these instructions with computational ones (say with Intrinsic::x86_sse2_min_pd as we have in the scenario). As a result, wrong floating point values are produced. The issue disappears when using llvm::CodeGenOpt::None instead of Default, but of course this is too big hammer for using as a workaround. Is it a bug, or am I missing some smart settings to prohibit reordering? Regards, Mikhail _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu<http://llvm.cs.uiuc.edu/> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140128/a1275246/attachment.html>