[llvm] [SandboxIR] Delete SandboxIR/SandboxVectorizer (PR #166417)

Aiden Grossman via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 4 21:53:27 PST 2025


boomanaiden154 wrote:

> The decision why this project was developed in tree in the first place was discussed in the [RFC](https://discourse.llvm.org/t/rfc-sandbox-vectorizer-an-experimental-modular-vectorizer/79059). I am not sure why this is being brought up again.

I'm familiar with the conversation there. I'm bringing this up again because the context surrounding the project has changed. At that point in time, the project was well funded and a lot of work was happening. Now the work is unfunded with the vectorizer not yet usable (at least in isolation) for production workloads.

> How did you come to this conclusion? Just because development is slow, it doesn't mean that there are no plans or interest in the project.
Please bear in mind that the project has been unfunded for one year and it was during this period that it became stable and has seen more than 100 patches land.

I guess plans/interest was not the right term. It does seem like you have plans and interest in completing it, but maybe a lack of time/resources/reviewers to see the project through quickly.

> There are plenty of components in LLVM without patches in the last couple of months. In the Sandbox Vectorizer's case there are at least pending patches in the pipeline. The only reason they haven't been checked in yet, is because I am trying to stick to the LLVM community's code review standards and get them thoroughly reviewed upstream by developers who are familiar with the codebase before landing. Just because a reviewer might be temporarily unavailable, it doesn't suggest that they won't be available in the future.

Having talked to all of the people who worked on this project at Google, it does not sound like there are any plans to continue reviewing these patches. I think if you want to make progress you are going to need to find new reviewers.

> Regarding the maintenance cost, I would argue that it hasn't been a burden to anyone yet. Nobody so far has raised any actual concerns regarding code maintenance, at least nobody has reached out to me. As the active maintainer, I am always available to help with any issues that show up.

Ack. It's not significant yet, but it is essentially dead code, which we typically try to remove.

I honestly think focusing on development out of tree would be better for this project. It seems like reviewer bandwidth is a large issue currently given the changes in backing. Developing out of tree would let you build out the rest of the vectorizer until it can compete with the existing SLPVectorizer implementation, which I think would help people justify spending their time reviewing the rest of the patches. And I think that can happen regardless of if this patch lands or not. If we land this patch, we remove the small yet real maintenance burden for now, and reverting should be easy given this code has already been reviewed. I know this is mostly a rehash of some of the conversations in the original RFC, but I think the lack of funding to finish the implementation changes things significantly.

If you still want to keep this in tree despite the reviewer bandwidth issue, can we come up with a soft timeline? Eg if no one is using/enabling this infrastructure anywhere, or there have been significant changes in reviewer bandwidth or funding in 12 months then we move it out of tree?

https://github.com/llvm/llvm-project/pull/166417


More information about the llvm-commits mailing list