[llvm] [SandboxIR][Region] Auxiliary vector metadata now requires a region (PR #137443)

via llvm-commits llvm-commits at lists.llvm.org
Fri May 23 19:12:30 PDT 2025


vporpo wrote:

When we add an instruction to the region "for real" its cost will always be counted, because the Sandbox IR callbacks will call `Region::add()` and count the cost. It's only when we add an instruction to an auxiliary vector that we don't count the cost, which makes sense because even though the instruction is tagged as being in the region it hasn't actually been added in the "normal" way, i.e., by creating it and adding it to the BB.

So yes, this patch breaks the assumption that the cost in the scoreboard corresponds to the instructions that are tagged as members of a Region, but I don't think this is a very important assumption. I think we should focus more on getting the Region design as nice as possible and not focus on its interaction with the cost tracking, because conceptually the cost tracking should be disjoint from the Region anyway. I mean the Region is an IR-level concept that helps us with serialization and deserialization, while the cost tracking is specific to the vectorizer and can be implemented in many different ways, including having it completely removed from Region.

I think the main question is whether we want to allow Aux instructions not being "members" of a region but still being "owned" by a Region.
For example with the help of "!ownedby" we could describe the following:
```
define void @foo(i8 %v) {
  %t0 = add i8 %v, 0, !sandboxvec !0, !sandboxaux !1 // %t0 is a member of region !0 and also at Aux[0] of region !0
  %t1 = add i8 %v, 1, !sandboxaux !1, !ownedby !0 // %t1 is not in Region !0 but it's in Aux[1]of region !0
  ret void
}
!0 = distinct !{!"sandboxregion"}
!1 = !{i32 0}
!2 = !{i32 1}
```
So when you parse the IR for this code you will create a Region, place `%t0` in its members and at `Aux[0]`, then add `%t1` to `Aux[1]` but not in its members.

But I think this complicates things a bit. I am trying to think of a reason why would want to support this other than the issue with the cost calculation.

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


More information about the llvm-commits mailing list