[PATCH] Disable passes on optnone functions

[Chandler Carruth]

On Wed, Jan 15, 2014 at 12:42 PM, Sean Silva <silvas at purdue.edu> wrote:

> On Wed, Jan 15, 2014 at 1:54 PM, Robinson, Paul <
> Paul_Robinson at playstation.sony.com> 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.
>>
>
>
> Ah, that makes sense.
>

And my concern with embedding this in the pass manager itself is actually
tied up in the fact that we want *some* passes to run, just not all of
them. This (to me) makes it really hard to do anywhere but in each pass.

The only other idea I have is to build something along the lines of two
pass managers that is each parameterized on a set of functions which it
applies to, but then we have hard phase-ordering problems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140115/42777c53/attachment.html>