[llvm-dev] Opt Bisect layering

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Mon May 21 18:28:43 PDT 2018


Ping - did this end up progressing? (I might've missed or forgotten about
anything coming out on the list)

On Thu, May 3, 2018 at 7:28 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote:

> David,
>
> we definitely need to address this issue and I did not forget about it.
>
> I'm still fleshing out a proposal on a generic solution for "pass
> execution control points",
> which was inspired by the new pass manager needs but then it appears
> we can largerly reuse the implementation for both managers.
>
> Since the implementation should be based on a special Analysis,
> it definitely will be able to address this layering issue (as a
> side-effect :).
>
> I very much hope to be able send something real to the list in less than a
> week.
>
> regards,
>   Fedor.
>
>
> On 04/24/2018 01:42 AM, David Blaikie wrote:
>
> Ping on this - any chance we can look at fixing the OptBisect layering
> here/now?
>
> Could we move the implementation into Analysis & require users to set it,
> rather than having it as a default value in IR?
>
> On Tue, Apr 3, 2018 at 9:25 AM David Blaikie <dblaikie at gmail.com> wrote:
>
>> On Tue, Apr 3, 2018 at 8:50 AM Fedor Sergeev <fedor.sergeev at azul.com>
>> wrote:
>>
>>>  > Pass Manager (PassManager.h) itself, does not - it's only templates,
>>> none of it depends on Region, Loop, etc.
>>> Well, true but the problem happens when you try to instantiate the thing.
>>> And for generic features like opt-bisection, ir-print-after-all etc that
>>> want:
>>>    - to have a say before/on/after every execution of every pass
>>>    - have a shared implementation of the main logic
>>>
>>> you have to do most of the following:
>>>    1. instantiate your interfaces for all the IRUnits
>>>    2. have pass manager doing the job for you directly
>>>    3. extend pass interface with specific helpers for your job
>>> (skipFunction)
>>>
>>> neither of those helps perfect layering...
>>> And with new pass manager having no common Pass hierarchy this gets even
>>> more clumsy.
>>>
>>
>> Not sure I follow, sorry - when you go to instantiate the pass manager &
>> the catch system - at that point there's a concrete set of passes (you have
>> a dependence on Analysis and Transforms) and entities (regions, loops, etc)
>> so the dependencies seem like they make sense.
>>
>>
>>>
>>>  > I'm happy to discuss/help design this area as well if you'd like :)
>>> Yeah, I'm interested to continue this design discussion, although my
>>> interests
>>> are primarily in the area of new pass manager currently.
>>> I'm going to post a separate RFC on that topic.
>>>
>>
>> Sounds good.
>>
>> Looping back for this thing - would it be reasonable to remove the
>> default OptBisect from IR, move it into Transform or some other leafier
>> dependency? Leaving only the basic interface (that can get away with
>> forward declarations of Region, Loop, etc) in IR? Is that likely to be done
>> in the patch under review, or shortly after it?
>>
>>
>>>
>>> regards,
>>>    Fedor.
>>>
>>> On 04/03/2018 06:16 PM, David Blaikie wrote:
>>>  >
>>>  >
>>>  > On Mon, Apr 2, 2018 at 11:32 PM Fedor Sergeev via llvm-dev
>>> <llvm-dev at lists.llvm.org> wrote:
>>>  >
>>>  >     On 03/30/2018 12:05 AM, David Blaikie via llvm-dev wrote:
>>>  >      > & now looking back at the patch-in-progress, I see it allows
>>> setting
>>>  >     the OptBisector/OptPassGate as suggested in (2).
>>>  >     Well, the patch currently discussed does not attempt to solve the
>>>  >     passgate object management issue.
>>>  >     It is left for the discretion of passgate object provider.
>>>  >
>>>  >      >
>>>  >      > If that becomes the /only/ option (ie: LLVMContext has no
>>> default
>>>  >     OptPassGate) then the virtual interface could be kept down in IR
>>> (though
>>>  >     it's still a bit questionable to have those Analysis types (Loop,
>>>  >     Region, CallGraphSCC) even declared in IR). Then the
>>> implementation of
>>>  >     OptBisector could be moved into Analysis - freely able to depend
>>> on the
>>>  >     concrete Analysis types.
>>>  >
>>>  >     To me this is a "Pass Manager catch" - entity that attempts to
>>> control
>>>  >     all the passes needs to be part of (or tightly cooperate with)
>>> pass manager.
>>>  >     Pass manager is currently in IR, and perhaps rightfully so.
>>>  >     Yet passes that it controls work on "IR units" which are either
>>> IR or
>>>  >     Analysis, thus Analysis leaks into the interfaces inevitably.
>>>  >     Kinda logical conflict it is...
>>>  >
>>>  >
>>>  > This is in response to my "it's still a bit questionable" comment?
>>> That's not too important - I'm not pushing to change that if we can get
>>> the mechanical layering functional regardless, by only having forward
>>> declarations of those different Analysis entities in llvm/IR, but not
>>> need their definitions except in the implementation of this virtual
>>> interface which could live in llvm/Analysis.
>>>  >
>>>  > But to discuss it anyway: It seems a bit different that the "Pass
>>> Manager catch" depends on the concrete types but the Pass Manager
>>> (PassManager.h) itself, does not - it's only templates, none of it
>>> depends on Region, Loop, etc. If the catch could be implemented
>>> similarly to the manager itself, then it'd have the same layering
>>> requirements & no problem. But I haven't looked closely enough at the
>>> APIs to figure out if/how that might be done - the current
>>> implementation/mechanisms are at odds because of the incompatibility of
>>> templates and virtual dispatch (can't have a virtual function template -
>>> it'd have an unbounded/unknowable number of vtable entries, etc). Some
>>> sort of visitor-y thing might be needed/useful, I'm not sure. But again,
>>> not sure this is necessary to address/fix for the issues I'm
>>> seeing/pushing to deal with - but I'm happy to discuss/help design this
>>> area as well if you'd like :)
>>>  >
>>>  > - Dave
>>>  >
>>>  >
>>>  >
>>>  >     regards,
>>>  >        Fedor.
>>>  >
>>>  >      >
>>>  >      > - Dave
>>>  >      >
>>>  >      > On Thu, Mar 29, 2018 at 2:01 PM David Blaikie
>>> <dblaikie at gmail.com> wrote:
>>>  >      >
>>>  >      >     So... looking at OptBisect, I have a few thoughts:
>>>  >      >
>>>  >      >     1) what's the purpose of the virtual
>>> interface/OptPassGate? I'm
>>>  >     guessing maybe that worked around the circular referencing in
>>> these
>>>  >     APIs? hmm, no, I suppose that wouldn't work/be relevant here.
>>>  >      >
>>>  >      >     2) Why is OptBisector a ManagedStatic? That seems pretty
>>>  >     antithetical to the role of LLVMContext. When/why would a user be
>>>  >     bisecting over multiple LLVMContexts? & even then, maybe it'd be
>>> more
>>>  >     suitable for that grouping (the scope for the bisection) to be API
>>>  >     driven - passing the bisector into the LLVMContext ctor to define
>>> the
>>>  >     set of contexts that share a bisector?
>>>  >      >
>>>  >      >     On Wed, Mar 21, 2018 at 10:20 PM Yevgeny Rouban via
>>> llvm-dev
>>>  >     <llvm-dev at lists.llvm.org> wrote:
>>>  >      >
>>>  >      >         Andrew,
>>>  >      >
>>>  >      >         I would not make the caller pass the description of
>>> the IR
>>>  >     unit. That is because it would result in the description
>>> generated every
>>>  >     time even if OptBisect is disabled. Description generation is not
>>> very chip.
>>>  >      >         Thinking on the OptBisect extension, I believe passing
>>> the
>>>  >     units are the right choice because OptPassGates may use them to
>>> make
>>>  >     pass skipping decisions.
>>>  >      >
>>>  >      >         -Yevgeny Rouban
>>>  >      > -----------------------------------------------------------
>>>  >      >
>>>  >      >         From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org]
>>> On
>>>  >     Behalf Of Kaylor, Andrew via llvm-dev
>>>  >      >         Sent: Thursday, March 22, 2018 3:52 AM
>>>  >      >         To: David Blaikie <dblaikie at gmail.com>; llvm-dev
>>>  >     <llvm-dev at lists.llvm.org>; Friedman, Eli <efriedma at codeaurora.org
>>> >
>>>  >      >         Subject: Re: [llvm-dev] Opt Bisect layering
>>>  >      >
>>>  >      >
>>>  >      >
>>>  >      >         There is a patch under review right now from someone
>>> who
>>>  >     wants to provide a mechanism to replace OptBisect as the pass gate
>>>  >     keeping mechanism.
>>>  >      >
>>>  >      >
>>>  >      >
>>>  >      >         https://reviews.llvm.org/D44464
>>>  >      >
>>>  >      >
>>>  >      >
>>>  >      >         Possibly we could take this opportunity to move
>>> OptBisect to
>>>  >     a different layer, though I don’t know where else it would belong.
>>>  >      >
>>>  >      >
>>>  >      >
>>>  >      >         The other possibility is that we could have the caller
>>> pass
>>>  >     in a description instead of a pointer to the pass and the IR unit.
>>>  >     OptBisect isn’t doing anything with them other than building a
>>> string
>>>  >     for output.
>>>  >      >
>>>  >      >
>>>  >      >
>>>  >      >         -Andy
>>>  >      >
>>>  >      > _______________________________________________
>>>  >      >         LLVM Developers mailing list
>>>  >      >         llvm-dev at lists.llvm.org
>>>  >      > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>  >      >
>>>  >      >
>>>  >      >
>>>  >      > _______________________________________________
>>>  >      > LLVM Developers mailing list
>>>  >      > llvm-dev at lists.llvm.org
>>>  >      > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>  >
>>>  >
>>>  >     _______________________________________________
>>>  >     LLVM Developers mailing list
>>>  >     llvm-dev at lists.llvm.org
>>>  >     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>  >
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180521/62ee4902/attachment.html>


More information about the llvm-dev mailing list