[llvm-dev] Opt Bisect layering

[Fedor Sergeev via llvm-dev]

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...

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