Displaying 3 results from an estimated 3 matches for "stmcxsr".
2017 Apr 20
4
[cfe-dev] FE_INEXACT being set for an exact conversion from float to unsigned long long
...pretend that floating point status bits don’t exist (at least before you get to the target-specific backend).
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.
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 s...
2017 Apr 19
3
[cfe-dev] FE_INEXACT being set for an exact conversion from float to unsigned long long
Changing the list from cfe-dev to llvm-dev
> On 20 Apr 2017, at 4:52 AM, Michael Clark <michaeljclark at mac.com> wrote:
>
> 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.
>
> I found a comment around the rationale for using a conditional move versus a branch. I believe the predicate logic
2017 Apr 21
2
[cfe-dev] FE_INEXACT being set for an exact conversion from float to unsigned long long
...double to unsigned need to round or clamp negative values to zero. I guess this is undefined behaviour in C.
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.
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 s...