[llvm-dev] Review wanted - contribution for legacy pass manager (machine pass extensions)
Raoul Gough via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 17 00:52:44 PDT 2021
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
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
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.
> 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.
> 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...
>> Raoul Gough.
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev