[TableGen] Add test showing incorrect SubRegIndex for a subreg of a subreg

[jayfoad]

R16 is the high 16 bits of R32, which is the high 32 bits of R64.

Therefore R16 is the high 16 bits of R64, i.e. bits 63..48. This needs
to be represented by a new SubRegIndex, but TableGen wrongly uses the
existing SubRegIndex hi16.

[jayfoad]

I believe this bug afflicts the SystemZ backend, which defines:

def subreg_l32   : SubRegIndex<32, 0>;  // Also acts as subreg_hl32.
def subreg_h32   : SubRegIndex<32, 32>; // Also acts as subreg_hh32.
...
def subreg_lh32  : ComposedSubRegIndex<subreg_l64, subreg_h32>;
def subreg_ll32  : ComposedSubRegIndex<subreg_l64, subreg_l32>;

These definitions make no sense to me, since lh32 should be identical to h32 and ll32 should be identical to l32; whereas hl32 and hh32 are different, and should have real definitions.

[uweigand]

These definitions make no sense to me, since lh32 should be identical to h32 and ll32 should be identical to l32; whereas hl32 and hh32 are different, and should have real definitions.

This is what we had originally, but then changed in e7c1b4b to fix #61390

Has anything changed in the meantime so that this workaround is no longer necessary?

[jayfoad]

These definitions make no sense to me, since lh32 should be identical to h32 and ll32 should be identical to l32; whereas hl32 and hh32 are different, and should have real definitions.

This is what we had originally, but then changed in e7c1b4b to fix #61390

Has anything changed in the meantime so that this workaround is no longer necessary?

Wow, there's a lot of history there, thanks for the link. No nothing has changed yet, but if I'm right then TableGen needs to be fixed, and that would probably require changing SystemZ back to the original (hopefully correct) subreg definitions. I will keep looking into it.