[PATCH] Caller/Calllee unsafe-fp-math attribute fixup prior to inlining.

[Chandler Carruth]

On Wed, Apr 16, 2014 at 12:23 AM, Puyan Lotfi <plotfi at apple.com> wrote:

> Hi Chandler
>
> I agree on #1 (per-instruction fast-math flags) being the ideal way to do
> unsafe math, but it would require we make non-trivial modifications to
> selectiondag in order to handle them on a per instruction granularity
> rather than as a function attribute. The purpose of the patch is to fixup
> the function attributes so that the backend doesn’t non-conservativly
> modify what should be safe code, given the current constraints.
>

I just don't think we should add hacks to the inliner rather than doing the
right thing here. The right thing is to lower these to instruction flags
and strip the function attributes returning the functions to conservatively
correct semantics. Once you do that, you'll just get performance problems
when selection dag isn't aware of them, but no correctness bugs. Then we
can incrementally fix selection dag to do the right thing with the
per-instruction flags.


> It would be easier to bail out of inlining and take the #2 route, but we
> have use-cases that actually require always_inline as well.
>

always_inline already has the constraint that it can only be used on
functions which the optimizer happens to be able to inline in every case.
For example, you can't effectively use it in certain circumstances with
dynamic allocas. But the point of #2 wasn't to pick some *specific*
solution of bailing on inlining. Instead, we could have the inliner always
strip any fp-math-safety function attributes from the caller when inlining
code into it from a callee with different fp-math-safety attributes. That's
always conservatively correct and doesn't interfere with inilining.

I don't expect that to be any more useful in *practice* or the real world
use cases. All either of these strategies do is provide a conservatively
correct and simple model for handling the function attributes if for some
reason they show up. They both *completely* rely on expressing fp math
safety constraints per-instruction rather than per-function to address
real-world use cases. Sorry if that wasn't clear.


> I think the ideal solution would be to refactor selectiondag in the
> backend to not use these function attributes and to handle per-instruction
> fast-math flags instead, but that would take major surgery to selectiondag.
>

Adding hacks to the inliner to do special things to string-named function
attributes when we have the *correct* design already well understood and in
place in the IR doesn't make sense to me. Any missed optimizations we have
when using the correct design in the IR due to selection dag weaknesses are
already problems and really need to be fixed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140416/3d19710e/attachment.html>