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

[Craig Topper via Phabricator via llvm-commits]

craig.topper added a comment.

In D82525#2603275 <https://reviews.llvm.org/D82525#2603275>, @sepavloff wrote:

> 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`.

Isn't X86 using this struct which is 8 bytes?

  typedef struct
    {
      unsigned short int __control_word;
      unsigned short int __glibc_reserved;
      unsigned int __mxcsr;
    }
  femode_t;


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82525