[llvm-dev] Review wanted - contribution for legacy pass manager (machine pass extensions)

[Raoul Gough via llvm-dev]

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>