[PATCH] D82525: [FPEnv] Intrinsics for access to FP control modes

[Serge Pavlov via Phabricator via llvm-commits]

sepavloff added a comment.

In D82525#2599988 <https://reviews.llvm.org/D82525#2599988>, @lebedev.ri wrote:

> From langref it isn't obvious if the following transform is valid or not
>
>   %z = fadd_strict %x, %y
>   call @llvm.set.fpmode.i16(i16 %fpenv)
>     =>
>   call @llvm.set.fpmode.i16(i16 %fpenv)
>   %z = fadd_strict %x, %y

Short mention about function ordering is added to the paragraph "Floating Point Environment Manipulation intrinsics".

In D82525#2600598 <https://reviews.llvm.org/D82525#2600598>, @craig.topper wrote:

> Is there any guarantee that femode_t will be the same layout for a given target in different C library implementations?

Strictly speaking there is no such guarantee. However the obvious implementation of `femode_t` is the type used to store content of FP control register. Most of 16 targets supported by glibc use `unsigned int` as `femode_t`.  Exceptions are alpha, ia64, sparc (`unsigned long`) and powerpc (`double`). In these cases `femode_t` is identical to `fenv_t`.



================
Comment at: llvm/test/CodeGen/Generic/fpenv.ll:35
+; CHECK:      sub  #2, r1
+; CHECK-NEXT: mov  r1, r12
+; CHECK-NEXT: call #fesetmode
----------------
craig.topper wrote:
> Is this missing the instructions that copy %fpenv into the stack temporary?
Indeed, due to incorrect chain argument supplied to the library function call, the store to stack disappeared.

Thank you for the catch!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82525/new/

https://reviews.llvm.org/D82525