[VE][TableGen] Corrupted LaneBitmask representing regLiveUnits for few registerClasses

[vg0204]

In VE codegen, the laneBitmask generated corresponding to regUnits (for MCRegister) via MCRegUnitMaskIterator is always corrupted (value being 0x0 irrespective of regunits) for registerClasses dealing with scalar i32 & f32 dataTypes.

Its happening specifically for SX#index registers (64-bit) which are constituted from subregs SW#index(32-bit) and SF#index (32-bit) respectively with respective subregIndex denoting position as sub_i32 and sub_i32. Now, as in Target.td, the rules for subreg for any registers suggests that these subregs cannot be overlapping(or aliases) with each other. For example, in X86, EAX's Subregs list contains only [AX], not [AX, AH, AL].

But, as its defined, SF#index is marked as an alias of SW#index, which makes them overlapping with each other OR technically the same register, and then also used as subregs for SX#index vioalating the tableGen rule, which causing the generation of exactly single regunit(with 2 roots register) of form SW#index~SF#index with consequently corrupted LaneBitmask value, instead of 2 regunits eventually reperesnting upper and lower halves of SX#index, with right laneBitmask

This is acting as a blocker for #129847, where I observed significant downfall in VE's LIT test due to corrupted LaneBitmask, causing incorrect livein addition at ISEL-phase.

[llvmbot]

@llvm/issue-subscribers-bug

Author: Vikash Gupta (vg0204)

[vg0204]

CC : @jayfoad @arsenm @Pierre-vh. Can you have a look at it!

[jayfoad]

VE uses "ad hoc aliasing", i.e. using the Aliases field in TableGen to force LLVM to think that two registers alias, even though the subreg info makes it look like they are disjoint. In TableGen this is modelled by creating a fake regunit shared by the two registers, but because it is not associated with any subreg info, it does not have a well defined lanemask. In practice if you query the lanemask for the fake regunit you get zero. This is probably what you're seeing.

See also #78942 and linked PRs.

cc @kaz7

[vg0204]

VE uses "ad hoc aliasing", i.e. using the Aliases field in TableGen to force LLVM to think that two registers alias, even though the subreg info makes it look like they are disjoint. In TableGen this is modelled by creating a fake regunit shared by the two registers, but because it is not associated with any subreg info, it does not have a well defined lanemask. In practice if you query the lanemask for the fake regunit you get zero. This is probably what you're seeing.

See also #78942 and linked PRs.

cc @kaz7

Yes, I am seeing it as zero. Also, Is it right to call it fake regUnit, rather than a regunit with 2 root registers Or is it the saying the same thing. Also, if the 2 registers are one in the same, how does it make sense to represent both upper 32bit and lower 32bit part of the sx registers from hardware's perspective, I am quite lost at that part in its visualization.