Thanks, Mehdi. I wasn't aware of that discussion; cc'ing those folks and
llvm-dev.
The earlier proposal distinguished between intrinsics and regular calls,
while this does not. This adds FMF to all calls that are FPMathOperators
(return FP or FP vector). I don't know if that makes it more or less
objectionable than the previous proposal.
Note the earlier suggestions/comments in the Phab review:
We could slide FMF into call instruction attributes, but I thought that was
worse given that FMF continues to evolve ( http://reviews.llvm.org/D14067 ).
There are a handful of places in LibCallSimplifier where we can use FMF on
calls today (and I already changed a few of those in recent commits). That
number will grow over time as we add more optimizations. In theory, we
could also use FMF on calls for DAG optimizations if we extend that too.
The main motivation for putting FMF on a call rather than relying on a
function-level attribute is the LTO case. There are also (insane?)
customers that want to specify relaxed/strict math at whatever granularity
we will allow via pragma in C source code. I think these are the same
motivations that drove FMF for IR FP math instructions in the first place.
This patch get us closer to the goal of mixed fast/strict math in LLVM. If
there's a better way to implement this, I'll try to help make it happen.