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

[Eric Christopher]

Yeah. I think the predicate lambda makes the most sense. Originally what
direction I thought we were going with this.

Akira: make sense?

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

> I meant either a predicate lambda, or a flag that gates hard-coded
> subtarget queries inside the pass, whichever makes more sense.
>
> On Wed, Apr 8, 2015 at 8:18 PM Eric Christopher <echristo at gmail.com>
> wrote:
>
>> Or do you mean a predicate lambda passed during pass construction? I'd be
>> totally down with that.
>>
>> On Wed, Apr 8, 2015, 8:17 PM Eric Christopher <echristo at gmail.com> wrote:
>>
>>>
>>> How would that work? A parameter doesn't get us subtarget Independence
>>> in the pass manager construction as far as I can tell. I could be dense
>>> here though.
>>>
>>> On Wed, Apr 8, 2015, 8:10 PM Chandler Carruth <chandlerc at google.com>
>>> wrote:
>>>
>>>> I'm suggesting rather than a decorator, we use an optional predicate
>>>> parameter when constructing the pass. To me, that seems somewhat cleaner.
>>>>
>>>> On Wed, Apr 8, 2015 at 8:09 PM Eric Christopher <echristo at gmail.com>
>>>> wrote:
>>>>
>>>>> 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/8f3b63d8/attachment.html>