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 <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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180322/207434b8/attachment.html>
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 > <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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180329/feb937d9/attachment.html>
& now looking back at the patch-in-progress, I see it allows setting the OptBisector/OptPassGate as suggested in (2). 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. - 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 >> <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 >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180329/0c8fd140/attachment.html>