[PATCH] D83036: [X86][FPEnv] Lowering of {get,set,reset}_fpmode

[Craig Topper via Phabricator via llvm-commits]

craig.topper added inline comments.


================
Comment at: llvm/test/CodeGen/X86/fpenv32.ll:16
+entry:
+  %v = call i32 @llvm.get.fpmode.i32()
+  ret i32 %v
----------------
sepavloff wrote:
> craig.topper wrote:
> > I'm still not clear who the intended user of these intrinsics are? How would they know when to use i32 and when to use i64?
> > who the intended user of these intrinsics are?
> 
> These intrinsics can be useful at least in these cases:
> * native implementation of `fegetmode`/`fesetmode`,
> * internally by compiler when it implements pragmas changing control modes. Such pragma acts only within a compound statement and control modes should be restored upon exit.
> 
> > How would they know when to use i32 and when to use i64?
> 
> This is a platform-dependent choice, just as the size of pointers.  We could encode them in `DataLayout` (see D71741).
> > who the intended user of these intrinsics are?
> 
> These intrinsics can be useful at least in these cases:
> * native implementation of `fegetmode`/`fesetmode`,
> * internally by compiler when it implements pragmas changing control modes. Such pragma acts only within a compound statement and control modes should be restored upon exit.

For the pragma case, would that mean the frontend would have to pass different values to the intrinsic for each target to match the target dependent behavior? Is the pragma also target specific? Or is there some target independent representation a frontend should be giving to llvm.

The ABI code in clang is a place where we have a ton of target specific rules in the frontend. It has come up many times on the mailing lists that this is bad design as every frontend needs to reimplement it. So I want to make sure we're being careful about the interface here and not creating work for frontends.

> 
> > How would they know when to use i32 and when to use i64?
> 
> This is a platform-dependent choice, just as the size of pointers.  We could encode them in `DataLayout` (see D71741).

Based on the tests here it appears the size to use is different on 32-bit mode depending on whether sse is enabled. DataLayout can't be dependent on subtarget features. It's derived from the target triple.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83036