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

[Puyan Lotfi]

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. 

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.

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.

-Puyan

On Apr 15, 2014, at 11:01 PM, Chandler Carruth <chandlerc at google.com> wrote:

> I understand what you're going for here, but I don't think this is the right approach.
> 
> We have per-instruction unsafe math flags *specifically* to make them work even in the presence of inlining. Given that, I don't understand why we want to have even remotely clever handling of the function attributes.
> 
> I would suggest:
> 
> 1) If we don't already do so, add a pass which propagates function attributes onto instruction attributes, and strips the function attributes.
> 2) Teach the inliner to simply refuse to inline across differently attributed functions.
> 
> #1 will make #2 only matter for non-canonical IR coming into the inliner by being conservatively correct.
> 
> 
> On Tue, Apr 15, 2014 at 10:22 PM, Puyan Lotfi <plotfi at apple.com> wrote:
> Ping.
> 
> 
> 
> 
> On Apr 10, 2014, at 10:10 PM, Puyan Lotfi <plotfi at apple.com> wrote:
> 
> > Hi All
> >
> > The following patch checks that when inlining a callee into a a caller with unsafe-fp-math set, that the callee also has the attribute for unsafe-fp-math set (or others that apply) too.
> > The idea is to make the caller being altered by inlining be as safe as the callee, and the check is made immediately prior to the actual inlining (where it will modify whatever function attributes necessary).
> >
> > Could someone review this please?
> >
> > Thanks
> >
> > -Puyan
> >
> > <unsafeattr2.patch>
> >
> > P.S.
> >
> > This is a ping of a patch I sent previously, but I thought I’d rewrite the email body for clarity. _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140416/409da88b/attachment.html>