[llvm] [TableGen] Apply the implied subregidx optimization more widely (PR #149709)

[Jason Eckhardt via llvm-commits]

nvjle wrote:

Hi @jayfoad , 

I quickly tried this on a downstream back-end and see some differences in our `XXXGenRegisterInfo.inc`. This may or may not be innocuous and I have not investigated in detail. Our static lit tests check out (at best a sanity check), but I/we haven't yet tried to run thousands of shaders for perf/correctness to be sure. I also have not yet had time to context-switch in `inferMatchingSuperRegClass`  (which I never fully understood in the first place), and the below may or may not be helpful.

A quick diff of the generated reg info shows a few differences along these lines for `getSubRegisterClass` (actual widths replaced by `x`/`y`/`i`/`j` until I can upstream this back-end):
```
Old:
     {  // GPRx_U_GPRy
       1,       // GPRx_U_GPRy:dsub0 -> GPRi_U_GPRj
       1,       // GPRx_U_GPRy:dsub1 -> GPRi_U_GPRj
       1,       // GPRx_U_GPRy:dsub2 -> GPRi_U_GPRj
       1,       // GPRx_U_GPRy:dsub3 -> GPRi_U_GPRj
       1,       // GPRx_U_GPRy:dsub4 -> GPRi_U_GPRj
       1,       // GPRx_U_GPRy:dsub5 -> GPRi_U_GPRj
       1,       // GPRx_U_GPRy:dsub6 -> GPRi_U_GPRj
       1,       // GPRx_U_GPRy:dsub7 -> GPRi_U_GPRj

New:
     {  // GPRx_U_GPRy
       4,       // GPRx_U_GPRy:dsub0 -> GPRi
       4,       // GPRx_U_GPRy:dsub1 -> GPRi
       4,       // GPRx_U_GPRy:dsub2 -> GPRi
       4,       // GPRx_U_GPRy:dsub3 -> GPRi
       4,       // GPRx_U_GPRy:dsub4 -> GPRi
       1,       // GPRx_U_GPRy:dsub5 -> GPRi_U_GPRj
       1,       // GPRx_U_GPRy:dsub6 -> GPRi_U_GPRj
       1,       // GPRx_U_GPRy:dsub7 -> GPRi_U_GPRj

``` 
Notably, all the differences are related to the union classes (RC1 union RC2) we use for Greedy's inflation mechanism. What seems to be happening is that `addSuperRegClass` below
```
     // RC injects completely into SubRC.
      if (SubSetVec.size() == RC->getMembers().size()) {
        SubRC.addSuperRegClass(SubIdx, RC);
```
no longer adds, e.g., `GPRx_U_GPRy` where it did before. 

This is just a heads-up that there is at least one back-end where there are reg info differences, but I cannot yet say whether this is actually a problem (including in our own very complicated register hierarchy with a proliferation of long tuple classes, overlaps, and inflation classes).

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