<div dir="ltr">I've noticed on our not-published target that the aggressive anti-dep breaker adds all super registers to zero groups once a register is live-in or live-out. See AggressiveAntiDepBreaker::StartBlock. It does so by using <a class="gmail-semantic-decoration" href="https://source.corp.google.com/piper///depot/google3/third_party/llvm/llvm-project/llvm/include/llvm/MC/MCRegisterInfo.h;rcl=327218176;l=772" style="margin:0px;padding:0px;box-sizing:border-box;border-color:rgba(0,0,0,0.12);color:inherit;text-decoration-line:none;font-family:monospace;font-size:medium;white-space:pre">MCRegAliasIterato</a>r and thus considers all of them cross-block. This means if there is a super register r0_r1, then r0 is considered zero group if r1 is, preventing r0 anti-dep ranges from being broken. First question, does this affect e.g. AArch64 and maybe worth looking at? I am not planning to do that.<div><br></div><div>In our target, we have several subtargets, with one supporting super register tuples like r0_r1 above, and another subtarget doesn't. Since register definitions can't be predicated in LLVM's current state, the super registers are present on the subtarget that doesn't support them. In order to maximize code sharing, a good way to solve this would be to inherit from the existing anti-dep breaker, instead of writing a separate one. The only thing preventing this is AggressiveAntiDepState being private. Any objections to me sending out a patch making "State" protected?</div><div><br></div><div>Thanks</div></div>