Right, I can see what you’re saying. The problem is that we “don’t know” what situation we’re in, so the infra has to make a decision about what to do in the absence of that knowledge.
Just to briefly explain what “safe” means when I use it: “extra” attributes aren’t really allowed to add new semantics to an op they are attached to. Transformations won’t know about them, they won’t be reliably propagated in all cases, and macro changes to the IR can break assumptions the attribute is trying to convey. In the case of LLVM, these problems didn’t usually manifest in first order issues, but in second order issues that only popped up with weird combinations of transformations. A consequence of this idea (that extra attributes are hints and can’t carry semantics) is that the “safe by default” thing to do is to drop them.
That said, I understand that you have a specific goal in mind and propagation is probably the right thing to do for these use cases. I can think of two specific paths forward:
-
We can define a schema for attributes, so the attributes themselves carry information about “I am safe to implicitly propagate”. We would nail down what that exactly means, but if we had that, you could put this bit on the attributes in question and we could make the infra look for it and propagate “just these” attributes.
-
You could change
scf.forto have an explicit array attribute which would usually be empty, but could have other “propagate-able hints”. The rewrites for scf.for would always manually move these things over, and we’d use the array attribute as the thing that distinguishes between “propagate-able” and not. This is a lower impact change on the system, that could build experience towards building the larger system.
-Chris