[LLVMdev] ldmxcsr reordering issue

[Mikhail Lyapunov]

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>