[PATCH] Add a callback to FunctionPass to enable skipping execution on a per-function basis

[Eric Christopher]

Right, I agree with this in general, but looking to avoid the weird
subtarget flags that I mentioned. Perhaps we should revisit Akira's
original idea of wrapping pass in a decorator if you want to pull it out of
the pass manager machinery?

On Wed, Apr 8, 2015, 8:04 PM Chandler Carruth <chandlerc at google.com> wrote:

> Actually, even this could be done cleanly.
>
> You could change the *pass* to accept the generic predicate in this case,
> and add one unpredicated version to the pipeline and add a predicated form
> later.
>
> I'm essentially trying to lift the predicate logic out of the pass
> management machinery and into the pass itself because that's where the
> motivation for a predicate comes from.
>
> On Wed, Apr 8, 2015 at 8:03 PM Chandler Carruth <chandlerc at google.com>
> wrote:
>
>> Is this a real use case or a hypothetical one? Because it seems somewhat
>> contrived to me...
>>
>> If there really is some predicate that necessitates really radically
>> different pass pipelines, I feel like they should be, well, two separate
>> pass pipelines.
>>
>> On Wed, Apr 8, 2015 at 7:54 PM Eric Christopher <echristo at gmail.com>
>> wrote:
>>
>>> Optnone, IMO, needs to be replaced by something less terrible.
>>>
>>> I'm not sure how this is going to work with the "I want to run the first
>>> cfgcleanup unconditionally, but not the second" without tying the
>>> subtargets to things like shouldRunCfgCleanup2().
>>>
>>> On Wed, Apr 8, 2015, 7:38 PM Sean Silva <chisophugis at gmail.com> wrote:
>>>
>>>> Adding Paul as this seems related to optnone.
>>>>
>>>> On Wed, Apr 8, 2015 at 7:31 PM, Chandler Carruth <chandlerc at gmail.com>
>>>> wrote:
>>>>
>>>>> I feel like we could do something much simpler than this. This feeling
>>>>> is predicated on one primary theory: most passes will run for most
>>>>> subtargets. Put another way, there will only be a small number of passes
>>>>> that we actually want to opt out of on a per-subtarget basis.
>>>>>
>>>>> If we think that's likely to be the case, here is an alternative
>>>>> suggestion:
>>>>>
>>>>> - Add bool-returning predicates for each pass to the subtarget base
>>>>> class (eg, "isIfConversionProfitable()") with the expected default ("true").
>>>>> - Override these for the subtargets that want to opt out.
>>>>> - Change the pass to directly get the subtarget, query it, and bail
>>>>> without doing anything if it gets "false".
>>>>>
>>>>> From looking at and thinking about if-conversion at least, this seems
>>>>> nicer to me. It makes someone working on the pass aware that there are
>>>>> subtarget profitability concerns, and it makes it very clear that we are
>>>>> *running* all of the passes, just that some have no effect on certain
>>>>> subtargets.
>>>>>
>>>>> This also matches how an optimization pass should query the function
>>>>> for the 'noopt' attribute and bail.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>
>>>>>
>>>>> http://reviews.llvm.org/D8717
>>>>>
>>>>> EMAIL PREFERENCES
>>>>>   http://reviews.llvm.org/settings/panel/emailpreferences/
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150409/23795a36/attachment.html>