[llvm-dev] Review wanted - contribution for legacy pass manager (machine pass extensions)
Raoul Gough via llvm-dev
llvm-dev at lists.llvm.org
Mon Sep 6 02:39:26 PDT 2021
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>
More information about the llvm-dev
mailing list