We can remove the SEW operand and encode the SEW value in TSFlags.
There are some exceptions that we can't remove the SEW operand:
- Mask load/store. Their SEW are always 1.
- Indexed load/store. Data SEW and index SEW can be different.
The MatcherTable in RISCVGenDAGISel.inc is reduced by 22808 bytes
and RISCVGenInstrInfo.inc has some reductions too. Besides, about
0.53% of compile-time can be reduced (not a stable result).
But it will also add some complexities and make the RVV pseudos
inconsistent.
I think this patch creates a scenario where !hasSEW(TSFlags) && pseudoNameContainsSEW(Opcode). This patch removes SEW operand from loads and stores that have SEW in the pseudo name. These instructions still have SEW information in them that we are not extracting in this function, since this creates the case !hasSEW(TSFlags) for these loads and stores.
Obviously we cannot return MachineOperand when SEW is a part of the Opcode name and not an operand. However, in the places that getSEWOp wants the MachineOperand just for the immediate value, then we should be able to say what that immediate is with getLog2SEW that either gets it from TSFlags or from Opcode (if it exists as a part of either).
I think the issue of missing opportunities to report SEW, in the case that it is only part of the opcode and not an operand also applies to getLog2SEW.