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

Craig Topper via llvm-dev llvm-dev at lists.llvm.org
Wed Jun 16 16:31:08 PDT 2021


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>


More information about the llvm-dev mailing list