Re: [PATCH] Implement ‘optnone’ attribute semantics

[NAKAMURA Takumi]

Paul, excuse me, I reverted it in r195339.

Could you try it with various triplets, for example, i686, &c?

...Takumi

2013/11/21 Robinson, Paul <Paul_Robinson at playstation.sony.com>:
> r195317, thanks Bill!
>
> Still waiting on Chandler for #2, not that I’m impatient or anything…
>
> --paulr
>
>
>
> From: Bill Wendling [mailto:isanbard at gmail.com]
> Sent: Tuesday, November 19, 2013 10:30 PM
> To: Robinson, Paul
> Cc: Chandler Carruth; llvm-commits at cs.uiuc.edu commits
> (llvm-commits at cs.uiuc.edu)
>
>
> Subject: Re: [PATCH] Implement ‘optnone’ attribute semantics
>
>
>
> 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
>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>