Re: [PATCH] Implement ‘optnone’ attribute semantics

[Bill Wendling]

Patch #3 LGTM.

Chandler should look at #2. :-)

-bw

On Nov 19, 2013, at 2:15 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote:

> New patch #2 (passes) and #3 (backend).
> --paulr
>  
> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf OfRobinson, Paul
> Sent: Monday, November 18, 2013 11:53 AM
> To: Chandler Carruth
> Cc: llvm-commits at cs.uiuc.edu commits (llvm-commits at cs.uiuc.edu)
> Subject: RE: [PATCH] Implement ‘optnone’ attribute semantics
>  
> We looked at having each pass decide whether to check ‘optnone’, and it seemed that refactoring that logic into PM was cleaner.  Also, PM seemed like the right place to make decisions about what passes would run…. Without PM involved, the chunk of code in each pass is more intrusive.  But we can do that.
> --paulr
>  
> From: Chandler Carruth [mailto:chandlerc at google.com] 
> Sent: Monday, November 18, 2013 12:17 AM
> To: Robinson, Paul
> Cc: llvm-commits at cs.uiuc.edu commits (llvm-commits at cs.uiuc.edu)
> Subject: Re: [PATCH] Implement ‘optnone’ attribute semantics
>  
>  
> On Wed, Nov 13, 2013 at 4:09 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote:
> Patch #2 deals with skipping optimization passes for 'optnone'
> functions.  This is probably the piece that has caused the most angst.
> We tried to minimize the fiddling with the dreaded Pass Manager, and
> made as straightforward and simple a change as we could come up with
> that got the job done.  That is:
> 
> We introduce a 'bool mustAlwaysRun()' method on passes, and say that
> an 'optnone' function doesn't run any function IR, loop, or basic
> block pass, unless that pass is marked 'mustAlwaysRun.'  The default
> for 'mustAlwaysRun' is true, so we explicitly turn it off for all the
> Transform passes that we do not want to run on an 'optnone' function.
> This is kind of tedious but is a mostly mechanical change.
> 
> Note that module-level passes will still consider 'optnone' functions.
> 
> I don't really like this approach.
>  
> In re-working the pass manager stuff it is really desirable that the pass interface narrow. And if you're going to have to update each transform pass to handle this attribute anyways, it would seem better to just go into each pass's run method and add an early exit if the attribute is set. Did folks see any problems with doing that?
> <2-optnone-Passes.patch><3-optnone-CodeGen.patch>_______________________________________________
> 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/20131119/020a95ac/attachment.html>