[PATCH] D138867: [RFC] Add new intrinsics and attribute to control accuracy of FP calls

[Andy Kaylor via Phabricator via llvm-commits]

andrew.w.kaylor added inline comments.


================
Comment at: llvm/docs/LangRef.rst:22593
+intrinsic has any callsite attributes begining with "fp-" that that code
+performing the transformation does not recognize.
+
----------------
kpn wrote:
> Is there any way to enforce this? If the constrained intrinsics are merged in with the non-constrained then we lose the safe-by-default property.
> 
> The paragraph above would be stronger if it said "must not" instead of using the word "should".
The safe-by-default property only ever came from the fact that existing optimizations didn't recognize the intrinsics at all. Initially we'd get that same benefit with these new intrinsics.

I was thinking I could add a function like FPBuiltinIntrinsic::hasUnrecognizedFPAttrs() that would take a list of IDs of FP attributes that the caller did know about. Then as we teach a pass to use these intrinsics, we can also bake in the list of attributes that the pass knows how to check for. I'm imagining a pattern something like this:

```
RecognizedFPAttrs.push_back(FPBuiltinIntrinsic::FP_MAX_ERROR);
if (FPI->hasUnrecognizedFPAttrs(RecognizedFPAttrs)
  return false;
if (FPI->getRequiredAccuracy() != None)
  return false;
// Do the transformation

```
How does that sound?


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

https://reviews.llvm.org/D138867