[PATCH] Disable passes on optnone functions

Robinson, Paul Paul_Robinson at playstation.sony.com
Wed Jan 15 10:54:37 PST 2014


> -----Original Message-----
> From: Sean Silva [mailto:silvas at purdue.edu]
> Sent: Tuesday, January 14, 2014 6:57 PM
> To: chandlerc at gmail.com; Robinson, Paul
> Cc: llvm-commits at cs.uiuc.edu; silvas at purdue.edu
> Subject: Re: [PATCH] Disable passes on optnone functions
> 
> 
>   Is there an email thread that decided on this direction? (so that I
> can catch up) It seems really odd (and difficult to maintain) to litter
> the codebase with checks in each pass.

There was this one, which has lots of other stuff on it and one comment
from Chandler not liking a less intrusive patch that added a flag and
caused the pass manager to make the decision instead of the individual
passes:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131111/194876.html

The implied model now is that every pass needs to be aware of the
attributes that would affect its operation, and Do The Right Thing(tm).
I'm not happy that it touches every transform pass either, but this is
specifically responding to Chandler's review comments.  It doesn't
expand the PassManager<->Pass interface, at the cost of widening the
IR<->Pass interface.

> 
>   In particular, what ever happened to just splitting all the notionally
> "optnone" functions into a separate module, and linking them back in at
> the end? That seems much more general. I don't see a response to
> <http://article.gmane.org/gmane.comp.compilers.llvm.cvs/160085> or a
> response to Nick's original suggestion (which was restricted to using
> the commandline tools). It seems very simple to split the module like
> that.

Except it totally fails for LTO.  I mentioned this to Nick at the
LLVM conference, which he accepted as a valid objection; sorry that
never got documented on the list.
--paulr

> 
> http://llvm-reviews.chandlerc.com/D2369





More information about the llvm-commits mailing list