MLIR / LLVM has a clear (review) process for adding new functionality, but when/how to remove abandoned functionality is less clear to me. Removing old code that is no longer needed is important for the long-term health of the project.
I’d like to discuss this in the context of the linalg-detensorize pass. My goal for this RFC is to come up with a set of guidelines for removing abandoned code.
History
Last functional change to linalg-detensorize was in May 2023. No functional changes / bug fixes since, only adjustments to C++ API changes.
August 2025: An NFC API change (dialect conversion-related) was submitted, but no reviews were received.
11 December 2025: A new LLVM contributor sent a patch to fix the bug, presumably as a first step to get involved in the project. No response on the PR. The contributor “pinged” the PR three times.
19 January 2026: I asked for clarification from the tensor maintainers and this is the answer that I received: I've never required it myself. I also don't know what the context surrounding this pass is. IMHO, lack of feedback makes this pass a candidate for removal.
Next Steps
I’d like to get your opinion:
What are the next steps here?
Based on the history of this pass, is it a candidate for removal?
What is the bar for removing code?
Here’s a possible guideline:
Send an RFC on Discourse and attach a PR that removes the code in question.
Wait one month for feedback.
If the community is in favor or no response to the RFC, ask a maintainer (or any other person) to approve the PR and merge it.
I think there’s little risk in deleting code like this: even if the owners/users don’t speak up publicly, they can always revert the deletion in the future if they actually need it. Dropping code that seems abandoned is not irreversible.
For 1, I don’t actually see a pass creation call added anywhere, so not sure the pass ever ends up in the pipeline, just found it from grepping around. I have no idea if this pass is useful in any of these contexts, but I don’t think it hurts to check downstream usage when at least evaluating these sorts of decisions. A lack of code updates does not necessarily mean the code is abandoned, it might just be stable and not need new work outside of API updates. An outstanding crash report I also do not think changes the calculus too much here depending upon the nature of the crash. In LLVM/clang, crash reports are a dime a dozen and spending engineering effort on fixing them might not be the best use of time (e.g., crash on invalid for a contrived input). Not sure whether or not that experience applies to MLIR.
I’m not saying this removal shouldn’t happen. A lack of upstream maintainers for this is reasonably concerning and certainly frustrating to the existing upstream maintainers. I just want to maybe provide some additional context.
Some of it is in various policies, but in general, if the only users are downstreams, and upstream is broken, then either someone fixes upstream, or the code is removed and downstream can keep on their forks.
There’s enough precedent for that in various llvm projects over the last decade.
If there is consensus that this is broken (which starts with this thread), then we should take steps to formulate a fix or a removal.
IIUC, @ftynse is one of the original authors, his insight would be valuable, here.
In general, if a piece of code is not modified anymore, it may mean that it is complete and works as intended. We want it that way. I also agree with the @boomanaiden154-1’s opinion about crash reports: we are getting a lot, most generated by fuzzers and other automation on exotic cases that are exceedingly rare in practice, and we don’t have dedicated resources to fix them.
The absence of reviews is more serious, in particular from tensor category maintainers since it falls under their responsibility. This is the relevant group of people who should say whether they are willing to keep maintaining this piece of code or not. If not, they should suggest or otherwise help find somebody who would maintain it and, if that proves impossible, the code should be deleted as per usual policy on unmaintained code. So returning this to you @rengolin as well as @jpienaar and @banach-space .
I don’t remember writing this and the history shows only a one-off bug fix from me.
I agree with the above. This was mostly about the lack of reviews, which indicates to me that either (1) nobody cares about this piece of code or (2) nobody is willing / has to the time to maintain this piece of code.
It can also be a bit discouraging for new contributors: we often advertise that “picking an issue from the bug tracker and fixing it” is a good way to become an active LLVM community member.
So let’s give it some more time to see if the tensor maintainers can find reviewers / maintainers. If unsuccessful, I’m going to ask for a few more approval on the removal PR and then merge it.
That still indicates a problem of “ownership” for a component IMO: a component is rarely “finished” and can be left without anyone caring about it. If there is no-one to care about bugs reported for a component that still might indicate a problem.
It would be great if we could integrate more fuzzing during the development and validation of new components: I find it harder to prioritize fuzzer-generated bug when they affect code untouched for years.
I agree though that not having reviewers is much much higher on the list of concerns! (for all the reasons you all mentioned above)
I’d not concern purely code changes as metric indeed. I do believe a component can work well enough that’s it’s not needing constant tweaks/engineering ROI isn’t there.
I’d mostly consider cases where the cost is high (changes often needed, flakey tests etc), and if no one cares about or uses it. The latter is difficult to know without asking. Also if there are no folks willing to review/maintain then also signal. This was over December and beginning of year has been rather busy, so easy to miss though.
In this case, this is used in IREE, if the contributor of the PR only intends to use this IREE side. It is indeed point towards moving it to IREE if no upstream maintainer. But I’d also query if the pass in isolation is useful but under documented/difficult to find vs niche. I’ll check but don’t recall any other uses of this pass.
Agreed. At the very least this would tell us what parts are “stable but working fine” versus “abandoned”. But fuzzing, and acting on the result of fuzzing, is really expensive, human-wise.
There is a third state between the two above: “stable for some downstream, broken for everybody else”. That was the focus of my previous comment.
That’s one option. Another would be if the IREE folks want to fix it upstream while continue to using it. That may involve creating use cases for upstream-only code, which may not be trivial.
But since it has been unused and abandoned for so long, then probably no one needs/wants it other than IREE, so likely the best case for now.
It would be good if a contributor to that project chimed in. The only GitHub handle from git log that I recognise is @j2kun - would you be able to help here?
Also, since that link points to TosaToLinalg, let’s ping @sjarus .
@bob.belcher I believe was the original author of this pass, with usage in IREE. The pass itself is direct (it is for linalg generic and for two different forms of scalar representations), so could see it getting to state of done-enough. Also seems at least one extra non-IREE usage (and pass makes sense outside context of IREE).
Indeed that is also good option especially as used outside (e.g., whether @Groverkss and co could do the review upstream as they would have been happy to do downstream). Given the frequency of changes to it and multiple users, it seems like low cost that benefits more. [the PR looks reasonable and just missed ping but also not active user, so focusing on process here more than specific instance].
I indeed introduced this pass for usage in IREE. However, I was not aware of the above activity at all. Sorry for missing that. I moved away from contributing to IREE awhile ago due to focusing on flang that’s why these issues dropped through the cracks.
If this is still needed, and it seems it is needed at least for now, I will go over the above issues and try to work through the issues as much as possible. But that won’t be before next week unfortunately because of some going on work I am doing now.
Again, apologies for dropping the ball here, I totally missed the above.
Slightly related topic: IREE is removing the dependency on shard (as a conversion to flow) because they don’t use it anymore.
I imagine this is related to @fschlimb’s current fixes and cleanup of the dialect, generating merge issues, leading to a reevaluation of IREE’s needs.
Upstream areas that don’t change may also hide downstream dependencies that are broken and/or unneeded. Improving upstream support also leads to clean ups in downstream projects.
The particular use cited in HEIR is obsolete and can be removed. We had originally used it to lower TOSA to linalg (I don’t recall why we thought we needed it for that), but now we don’t use TOSA anymore.
TosaToLinalg is in active production use within Arm. @psunn, @leandron can you please establish whether the dependency on the detensorize pass is relevant and how it could be supported ?
Seems sensible. In practice, it is nearly trivial like jakub says to bring leaf features back later if needed (likely into a downstream). The inability to get a bug fix reviewed seems like a strong signal, and it would be good to garbage collect such components.
It would be a little bit more troubling if it was concluded that an entire subsystem were deemed dead and removed (ie. Data flow framework, python API, etc). But even then, upstream maintainability seems like a key principle to hold to, and I’d expect the RFC to be enough to force the discussion/resolution.
In this specific case, I don’t think this ever really worked as needed and is effectively orphaned in IREE too – which is going through its own garbage collection process and not opposed to such cleanups of the commons.