[llvm] Question: What is the correct interpretation of LaneBitmask? (PR #109797)

[Sander de Smalen via llvm-commits]

sdesmalen-arm wrote:

Thanks for the quick feedback!

> We probably need to require fully covering artificial register definitions to fully move the infrastructure to using register units (e.g. replacing livein tracking with regunits instead of registers, and for using regunit masks instead of regmasks)

Does the approach of using register units (instead of registers) have any impact on the existence or future use of the LaneBitmask?

> As it is today, I believe the intent is statement 1. However, I think we would be in a better place if we did require 2. We do have a number of issues whenever there are pieces of registers that aren't fully covered by a defined register, and it is harder to reason about.

I have some local patches that define registers/subreg-indices for the top bits, but then ran into an issue that the `uint64_t` to represent the `LaneBitmask` is no longer sufficient. It can be changed to use an `APInt` but I'm not sure if there's a way to define the BitWidth on a per-target basis (at least, not without passing some Subtarget to the LaneBitmask constructor). I haven't yet tried to see what the impact is on compile-time/memory-usage, or whether there is a way to limit this on a per-target basis, but this is a downside of having to define the top bits.

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