[PATCH] Disable passes on optnone functions

Nick Lewycky nicholas at mxc.ca
Sat Jan 18 14:30:57 PST 2014


Robinson, Paul wrote:
>> -----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.

I was about to reply with exactly that. Thanks!



More information about the llvm-commits mailing list