[Diffusion] rG76c22b18eafd: [FPEnv][AMDGPU] Correct strictfp tests.

[Matt Arsenault via Phabricator via llvm-commits]

arsenm added a comment.

In rG76c22b18eafd2156568d72e9df2ff7bd3457888a#1234182 <https://reviews.llvm.org/rG76c22b18eafd2156568d72e9df2ff7bd3457888a#1234182>, @kpn wrote:

> How would an fpenv-access attribute work? How would we verify that it was always correctly used, or at least always supplied when required?

I envision it looking something like the memory attribute, indicating read/write access to different aspects of the floating point mode (errno, flags, rounding mode, denorm mode, other, etc.). It would be applied to intrinsic definitions (and you just have to trust that intrinsics are correctly defined). If there is any read or write accesses for any fpenv property, the call site would have to be strictfp in a strictfp function. We could potentially just repurpose the current strictfp and just augment it with a field.

Although really I don't think strictfp call sites are the answer. I think we need a dedicated strictfp call instruction, like I posted about <https://discourse.llvm.org/t/thought-on-strictfp-support/71453> rather than needing to redefine every intrinsic (which really doesn't scale to every target intrinsic). The verifier would then enforce using "call strictfp" in strictfp functions if the callee has any fpenv access.

> Should the lack of an fpenv-access attribute block landing the Verifier changes that should have landed years ago? Because that's what I'm trying to get to: land D146845 <https://reviews.llvm.org/D146845>.

No, but it would help towards address target intrinsic handling. It's better to have a slightly annoying verifier than none


BRANCHES
  main

Users:
  kpn (Author)
  arsenm (Auditor)

https://reviews.llvm.org/rG76c22b18eafd