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.
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.
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 ⚙ D98591 [CodeGen] Add extension points for TargetPassConfig::addMachinePasses ? 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?
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.
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.
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 and would probably need to be rebased again if we want to go ahead with it.