[PATCH] D146845: [FPEnv] [WIP] Verify strictfp attribute correctness, first part, 2023 edition

[Matt Arsenault via Phabricator via llvm-commits]

arsenm requested changes to this revision.
arsenm added inline comments.
This revision now requires changes to proceed.


================
Comment at: llvm/test/Verifier/fp-intrinsics.ll:54-58
+; Test for mismatched function and function call attributes
+; CHECK-NEXT: Functions and their contained calls and invokes must match in use of attribute strictfp!
+; CHECK-NEXT: ptr @f6
+; CHECK-NEXT:  %fadd = call double @llvm.experimental.constrained.sqrt.f64(double %a, metadata !"round.dynamic", metadata !"fpexcept.strict")
+define double @f6(double %a) #0 {
----------------
arsenm wrote:
> Something is wrong here, there should be no error. The parent function has strictfp, and strictfp should always be implied by the intrinsic definition 
I think I see the issue, the constrained intrinsics are not marked strictfp.

This is related to the issue I posted about [[ https://discourse.llvm.org/t/thought-on-strictfp-support/71453 | here ]]. We should have some kind of fpenv access attribute that indicates whether an intrinsic may read or write the mode such that the verifier can more systematically enforce this. It would be nicer than having to separately update ConstrainedOps.def


================
Comment at: llvm/test/Verifier/fp-intrinsics.ll:183
+contb:
+  %1 = landingpad { i8*, i32 }
+          filter [0 x i8*] zeroinitializer
----------------
Needs to update to opaque pointers 


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

https://reviews.llvm.org/D146845