[PATCH] D24816: [Target] move reciprocal estimate settings from TargetOptions to TargetLowering

[Sanjay Patel via llvm-commits]

spatel added a comment.

In https://reviews.llvm.org/D24816#549822, @mehdi_amini wrote:

> In https://reviews.llvm.org/D24816#549812, @spatel wrote:
>
> > > What happens during inlining with this patch?
> >
> >
> > [spends some quality time in the debugger because I've never looked at how the inliner works]
> >  The caller's attributes are applied to the inlined code. My initial take is that this is legal, but not ideal (ie, all of -mrecip is supposed to be gated by fast/unsafe math).
>
>
> Is it legal?
>  You said that this is a tradeoff speed/precision that is made by the programmer. If the cursor is set on "speed" on the caller, inlining a callee where it is not the case would lead to less precision for the callee code.


Yes - but that's where the protective cover of -ffast-math comes into play. We were already issued a license to go crazy...just how crazy is up to artistic interpretation. Keep in mind that we already generate reciprocal estimates with -ffast-math (with some guidance from the target about the default codegen). The -mrecip attributes should give us more clues about what the programmer wants, but we make no guarantees about what they'll get.


https://reviews.llvm.org/D24816