For the record, I am a downstream user who is speaking up.
Migrating a customized downstream from legacy pass manager to new pass manager involves more than just porting a few passes. Several passes (such as the inliner) were rewritten from scratch. Effort was made to make the new versions of these rewritten passes match the original, but the interaction of the whole pass pipeline can be very fickle. What was determined to be good enough upstream might not be quite right in the face of downstream modifications. And if these rewritten passes were customized, then these customizations will be lost. Additionally, the construction of the pass pipeline has been fine tuned over years by the community, and by downstream users to produce good results, and mitigating regressions caused by switching to the new pass manager takes time. It’s easy to miss changes, and this can result in spending a bunch of time trying to figure out why some workload had a 3% regression.
I deal with this stuff every day at work, so I feel the pain of maintaining two pass infrastructures. However, I don’t understand what the hurry is. Who is blocked by legacy pass manager remaining operational? If maintaining the legacy pass manager is slowing the velocity of development in upstream, I think it’s reasonable to put it on life support and only fix correctness issues and egregious perf regressions. Downstreams that are ready can stop supporting it, but I don’t see why we can’t wait 6 more months to begin deleting code in upstream. I feel like “one whole release” is a pretty standard minimum period of time to deprecate major functionality in a software project. Sure, it’s been a long time coming, but legacy pass manager was never deprecated. No date was ever given for its removal.
I think that it is reasonable to state that legacy pass manager will be removed in the release of LLVM 14, and once the version string of main is set to 15 it’s open season to immediately begin gutting it. Prior to that, only a minimal level of effort need be made to maintain performance of the legacy pass manager. (i.e., downstreams who care about it can fix the bugs themselves) In the meantime, we can migrate the lit tests to new pass manager. New code that is added should prioritize the performance of the pass pipeline constructed with the new pass manager over that of the legacy pass manager. New passes that are added need not be ported to the legacy pass manager. All I’m asking is that we not delete code until we’ve had a real deprecation period.
Thanks,
Chris Tetreault