Craig Topper via llvm-dev
2021-Jun-16 23:31 UTC
[llvm-dev] Review wanted - contribution for legacy pass manager (machine pass extensions)
I just got back from vacation so I haven't had much time to look at your patch yet. My first question is going to be, is this something that can already be done with the existing TargetPassConfig::insertPassAfter mechanism? I don't know the history of that mechanism just that it exists. ~Craig On Wed, Jun 16, 2021 at 12:59 PM Raoul Gough <github.drti at gmail.com> wrote:> Hi Craig, I see you listed as the code owner for the x86 backend and I was > wondering if you'd have time to comment on my review at > https://reviews.llvm.org/D98591 ? This adds an extension mechanism to TargetPassConfig > to allow out-of-tree code to provide machine passes for an existing target. > > Arthur has raised the question of whether it's appropriate to have such an > extension mechanism so it might help if I explain my motivating example. > I'm working on a way to do runtime inlining of functions referenced via > pointers, including C++ virtual function calls. This works using > ahead-of-time compiled code that has been annotated to derive call-tree > information at runtime and potentially recompile parts of the code using > bitcode embedded as data in the executable. To build the call tree I > install a context pointer in a callee-saved register at the relevant call > sites and retrieve it at function entry, both of which I do via a machine > pass that runs just before the register allocator. There are actually > several other complications but that's the starting point for wanting to > inject a custom machine pass for an existing target. What do you think? > > There are some more details on my github page https://github.com/drti/drti > if you're interested. > > Regards, > Raoul. > > On 15/06/2021 23:22, Arthur Eubanks wrote: > > I'm not super familiar with the codegen pipeline, perhaps some backend > people can take a look? > > A question is, do we want extensions like in the middle-end optimization > pipeline? I don't see why not, this mirrors the existing extensions for the > optimization pipeline. But it'd be good to get some more opinions from > people more knowledgeable. > > On Mon, Jun 14, 2021 at 8:04 AM David Blaikie <dblaikie at gmail.com> wrote: > >> Arthur - any idea who might be good to review this? >> >> On Mon, Jun 7, 2021 at 6:20 AM Raoul Gough via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hello llvm-dev, I have a code contribution for the legacy pass manager >>> and I'm having trouble finding anyone to finish reviewing it. I've made >>> some improvements based on earlier feedback from @ychen on Phabricator >>> but since then nobody has given final approval. Can anyone help with >>> this or point me in the right direction? >>> >>> I couldn't see anyone listed in the CODE_OWNERS.txt for this area of the >>> code base. From what I understand the new pass manager still doesn't >>> handle the target-specific code, so I think the code is in the right >>> place for now at least. I'd be happy to move it to the new pass manager >>> if that's currently possible, of course. >>> >>> This is related to my (out of tree) runtime inlining project and adds >>> minimal support for target-level extensions in a similar way to >>> addGlobalExtension in the legacy IR PassManagerBuilder... >>> https://reviews.llvm.org/D98591 >>> >>> Regards, >>> Raoul Gough. >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://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/20210616/e6c04d82/attachment.html>
Raoul Gough via llvm-dev
2021-Jun-17 07:52 UTC
[llvm-dev] Review wanted - contribution for legacy pass manager (machine pass extensions)
Thanks for looking at this. Just so you're aware I see that @ychen has just posted some further comments on the review which I'll be addressing shortly. The TargetPassConfig::insertPass (after) function would work in theory except that the TargetPassConfig objects only have transitory lifetimes within, e.g., LLVMTargetMachine::addPassesToEmitFile. I couldn't find any existing way to access the TargetPassConfig objects from out-of-tree code in order to manipulate them. The solution with TargetPassConfig::addExtensionis to register callback(s) in a global which get passed the TargetPassConfig object during execution of TargetPassConfig::addMachinePasses. On 17/06/2021 00:31, Craig Topper wrote:> I just got back from vacation so I haven't had much time to look at > your patch yet. My first question is going to be, is this something > that can already be done with the existing > TargetPassConfig::insertPassAfter mechanism? I don't know the history > of that mechanism just that it exists. > > ~Craig > > > On Wed, Jun 16, 2021 at 12:59 PM Raoul Gough <github.drti at gmail.com > <mailto:github.drti at gmail.com>> wrote: > > Hi Craig, I see you listed as the code owner for the x86 backend > and I was wondering if you'd have time to comment on my review at > https://reviews.llvm.org/D98591 <https://reviews.llvm.org/D98591> > ? This adds an extension mechanism to TargetPassConfig to allow > out-of-tree code to provide machine passes for an existing target. > > Arthur has raised the question of whether it's appropriate to have > such an extension mechanism so it might help if I explain my > motivating example. I'm working on a way to do runtime inlining of > functions referenced via pointers, including C++ virtual function > calls. This works using ahead-of-time compiled code that has been > annotated to derive call-tree information at runtime and > potentially recompile parts of the code using bitcode embedded as > data in the executable. To build the call tree I install a context > pointer in a callee-saved register at the relevant call sites and > retrieve it at function entry, both of which I do via a machine > pass that runs just before the register allocator. There are > actually several other complications but that's the starting point > for wanting to inject a custom machine pass for an existing > target. What do you think? > > There are some more details on my github page > https://github.com/drti/drti <https://github.com/drti/drti> if > you're interested. > > Regards, > Raoul. > > On 15/06/2021 23:22, Arthur Eubanks wrote: >> I'm not super familiar with the codegen pipeline, perhaps some >> backend people can take a look? >> >> A question is, do we want extensions like in the middle-end >> optimization pipeline? I don't see why not, this mirrors the >> existing extensions for the optimization pipeline. But it'd be >> good to get some more opinions from people more knowledgeable. >> >> On Mon, Jun 14, 2021 at 8:04 AM David Blaikie <dblaikie at gmail.com >> <mailto:dblaikie at gmail.com>> wrote: >> >> Arthur - any idea who might be good to review this? >> >> On Mon, Jun 7, 2021 at 6:20 AM Raoul Gough via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hello llvm-dev, I have a code contribution for the legacy >> pass manager >> and I'm having trouble finding anyone to finish reviewing >> it. I've made >> some improvements based on earlier feedback from @ychen >> on Phabricator >> but since then nobody has given final approval. Can >> anyone help with >> this or point me in the right direction? >> >> I couldn't see anyone listed in the CODE_OWNERS.txt for >> this area of the >> code base. From what I understand the new pass manager >> still doesn't >> handle the target-specific code, so I think the code is >> in the right >> place for now at least. I'd be happy to move it to the >> new pass manager >> if that's currently possible, of course. >> >> This is related to my (out of tree) runtime inlining >> project and adds >> minimal support for target-level extensions in a similar >> way to >> addGlobalExtension in the legacy IR PassManagerBuilder... >> https://reviews.llvm.org/D98591 >> <https://reviews.llvm.org/D98591> >> >> Regards, >> Raoul Gough. >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> <https://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/20210617/967553de/attachment.html>
Raoul Gough via llvm-dev
2021-Sep-06 09:39 UTC
[llvm-dev] Review wanted - contribution for legacy pass manager (machine pass extensions)
Hello, sorry to revisit this old thread but progress seems to have stalled on my review again. It's been nearly six months since I submitted it and I didn't really think it would be such a hard change to get through. Is there a point when we could consider the original reviewer no longer to be interested and ask someone else to step in? What I've done is add a new (static) function addExtension to TargetPassConfig to give out of tree code a way to manipulate MachineFunctions. I did get some good feedback and made some code changes but I haven't been getting any responses for a while now and it's hard for me to know what to do at this point. Would someone else be able to take a look, please? The review is at https://reviews.llvm.org/D98591 and would probably need to be rebased again if we want to go ahead with it. Regards, Raoul. On 17/06/2021 08:52, Raoul Gough wrote:> Thanks for looking at this. Just so you're aware I see that @ychen has > just posted some further comments on the review which I'll be > addressing shortly. > > The TargetPassConfig::insertPass (after) function would work in theory > except that the TargetPassConfig objects only have transitory > lifetimes within, e.g., LLVMTargetMachine::addPassesToEmitFile. I > couldn't find any existing way to access the TargetPassConfig objects > from out-of-tree code in order to manipulate them. The solution with > TargetPassConfig::addExtensionis to register callback(s) in a global > which get passed the TargetPassConfig object during execution of > TargetPassConfig::addMachinePasses. > > > On 17/06/2021 00:31, Craig Topper wrote: >> I just got back from vacation so I haven't had much time to look at >> your patch yet. My first question is going to be, is this something >> that can already be done with the existing >> TargetPassConfig::insertPassAfter mechanism? I don't know the history >> of that mechanism just that it exists. >> >> ~Craig >> >> >> On Wed, Jun 16, 2021 at 12:59 PM Raoul Gough <github.drti at gmail.com >> <mailto:github.drti at gmail.com>> wrote: >> >> Hi Craig, I see you listed as the code owner for the x86 backend >> and I was wondering if you'd have time to comment on my review at >> https://reviews.llvm.org/D98591 <https://reviews.llvm.org/D98591> >> ? This adds an extension mechanism to TargetPassConfig to allow >> out-of-tree code to provide machine passes for an existing target. >> >> Arthur has raised the question of whether it's appropriate to >> have such an extension mechanism so it might help if I explain my >> motivating example. I'm working on a way to do runtime inlining >> of functions referenced via pointers, including C++ virtual >> function calls. This works using ahead-of-time compiled code that >> has been annotated to derive call-tree information at runtime and >> potentially recompile parts of the code using bitcode embedded as >> data in the executable. To build the call tree I install a >> context pointer in a callee-saved register at the relevant call >> sites and retrieve it at function entry, both of which I do via a >> machine pass that runs just before the register allocator. There >> are actually several other complications but that's the starting >> point for wanting to inject a custom machine pass for an existing >> target. What do you think? >> >> There are some more details on my github page >> https://github.com/drti/drti <https://github.com/drti/drti> if >> you're interested. >> >> Regards, >> Raoul. >> >> On 15/06/2021 23:22, Arthur Eubanks wrote: >>> I'm not super familiar with the codegen pipeline, perhaps some >>> backend people can take a look? >>> >>> A question is, do we want extensions like in the middle-end >>> optimization pipeline? I don't see why not, this mirrors the >>> existing extensions for the optimization pipeline. But it'd be >>> good to get some more opinions from people more knowledgeable. >>> >>> On Mon, Jun 14, 2021 at 8:04 AM David Blaikie >>> <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >>> >>> Arthur - any idea who might be good to review this? >>> >>> On Mon, Jun 7, 2021 at 6:20 AM Raoul Gough via llvm-dev >>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> >>> wrote: >>> >>> Hello llvm-dev, I have a code contribution for the >>> legacy pass manager >>> and I'm having trouble finding anyone to finish >>> reviewing it. I've made >>> some improvements based on earlier feedback from @ychen >>> on Phabricator >>> but since then nobody has given final approval. Can >>> anyone help with >>> this or point me in the right direction? >>> >>> I couldn't see anyone listed in the CODE_OWNERS.txt for >>> this area of the >>> code base. From what I understand the new pass manager >>> still doesn't >>> handle the target-specific code, so I think the code is >>> in the right >>> place for now at least. I'd be happy to move it to the >>> new pass manager >>> if that's currently possible, of course. >>> >>> This is related to my (out of tree) runtime inlining >>> project and adds >>> minimal support for target-level extensions in a similar >>> way to >>> addGlobalExtension in the legacy IR PassManagerBuilder... >>> https://reviews.llvm.org/D98591 >>> <https://reviews.llvm.org/D98591> >>> >>> Regards, >>> Raoul Gough. >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> <https://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/20210906/f3056527/attachment.html>