[LLVMdev] ldmxcsr reordering issue

[Nadav Rotem]

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>