The Machine Outliner (llvm/lib/CodeGen/MachineOutliner.cpp), which operates on MIR and has been deployed by several architectures.
The IR Outliner (llvm/lib/Transforms/IPO/IROutliner.cpp), which operates on LLVM IR, and is still disabled by default.
We have been looking at the IR Outliner, but have been finding various issues with it. I’m not sure who is maintaining the pass upstream - most recent changes have been minor fixes, or relating to debug info representation/API changes.
In the short term, is there someone who knows about the IR Outliner and is willing to review patches against it?
It would also be good to understand the longer-term aims/direction of this pass. I cannot tell how close it is to being enabled-by-default, but it has been around upstream without much attention for years now. Is there a list of specific issues to address so it can graduate from its current limbo to enabled more widely (at applicable optimisation levels)?
It would also be good to understand the longer-term aims/direction of this pass. I cannot tell how close it is to being enabled-by-default, but it has been around upstream without much attention for years now. Is there a list of specific issues to address so it can graduate from its current limbo to enabled more widely (at applicable optimisation levels)?
I feel there were some passes which was added for publishing papers… they are not enabled by default and there is no developers who are trying to make them enabled by default… not blaming any one but this feels pity
The IR outliner is broken with immarg intrinsics. I started working on this a long time ago but never finished if anyone wants to pick it up. IIRC I managed to fix it in a way that was overly conservative.
Yes, it’s fair to see it that way. I guess the main difference between HotColdSplit and IROutliner is HotColdSplit isn’t looking for similarity between split regions (which both the outliners are)
Thanks for pointing this out, and working on the issues.
I think making the pass correct but conservative so it can be enabled, and then later improving it is probably the way to go. LLVM has plenty of FIXMEs, what’s a few more between friends. I will try to pull together a list of known issues at the moment, so we at least know where we’ve got to with it
Given your familiarity (I note you had some of the more recent patches to IROutliner that actually changed how it worked rather than just general LLVM code improvements), maybe I should be tagging you in reviews? I’m mindful that you already have quite a big workload of reviews, so I haven’t yet.
I think the only thing I didn’t find in the issue tracker was anything about immarg, but I’ve linked to the WIP branch as we know there’s problems there.
Given that the IROutliner is unmaintained, not part of the default pipeline, and has significant issues, per our policy, either a maintainer should step up for it, or it should be removed.
Are there any downstreams who are using this pass and are willing to maintain it? Failing that, is there anyone else with sufficient interest in this pass to take over maintenance and resolve existing issues?
I do not have the expertise in the code to become the maintainer. I’ve done some minor changes but they were surface-level, and some important bugs that we’re hitting I’ve not been able to solve (both for lack of time and lack of understanding).
I said this on an IR Outliner patch recently, which I stand by:
One reason I slightly gave up is that even if this bug is squashed, the IR Outliner is so restricted in what it can actually outline that it’s a little pointless to enable, IMO. I don’t have the time to prioritise work on it so we told our users who were enabling it manually not to.
I know lots of work has gone into the IR Outliner (it’s a large, complex feature), but I think this was from a small set of people, and they are no longer active.
I initially showed interest, but ultimately it doesn’t make sense for me to be a maintainer for now. If no one is up to it, it is probably best to remove the pass.