[llvm] [CodeGen] Utilizing register units based liveIns tracking in MBB (PR #129847)

[Matt Arsenault via llvm-commits]

arsenm wrote:

> @arsenm don't you think it's as a big change (from its impact perspective, even not if implementation) that it can break everything, as unlike just introduction of optional laneBitmask to physeg, as supported now, is an extension which supported backward compatability, but this will need compulsory changes in every test files for all archs, as we are supposedly completely stripping physReg concept, replacing with regunits as block liveins , so what about this?

There is no compatibility concern, and every target will need to be updated. Just introducing a parallel structure with the same purpose is actively harmful. This is a full migration effort, I don't see how it makes sense for both livein representations to coexist. It will only provide a new source of inconsistency bugs and waste compile time maintaining both cases.

> 
> `Secondly, liveins as the regunit mask in someway (alongwith physReg) & representing them completely as register units apparently seems same but are 2 things as in the latter, the concept of liveins as physReg will vanish irreversibly causing significant downfall at use-site of liveins()`

What do you mean by "significant downfall"? Conceptually I don't see why you should need to enumerate the live in registers frequently. Most uses care about whether the register is live or not

> will be transformed into :
> liveins: $vgpr0_lo16, $vgpr0_hi16, $vgpr4, $vgpr5_hi16
> Does it make sense, along the line of my doubts just mentioned above?

This is the whole point, re-encode the live-ins in terms of register units 

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