[RISCV] Remove SEW operand for load/store and SEW-aware pseudos

[wangpc]

Summary

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:

1. Mask load/store. Their SEW are always 1.
2. 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.

[wangpc]

Resolved all issues.

[michaelmaitland]

I wonder if it would be a good idea to add a function getSEW(MachineInstr) which gets the SEW from the Opcode or from the Operand, depending on how the pseudo tracks SEW. This indirection would remove the complication of having inconsistent pseudos. WDYT?

[kito-cheng]

llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp

50–51

This seems could be a separated NFC refactor patch?

[wangpc]

Rebase and do some refactors.

[wangpc]

In D159368#4638327, @michaelmaitland wrote:

I wonder if it would be a good idea to add a function getSEW(MachineInstr) which gets the SEW from the Opcode or from the Operand, depending on how the pseudo tracks SEW. This indirection would remove the complication of having inconsistent pseudos. WDYT?

Done, I added a getSEWOp.

llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp

50–51

No, we have changed how it is used. We should use getSEWOp now.

[wangpc]

Rename sew_div_8 to sewDividedBy8.

[michaelmaitland]

llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h

233

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.

[wangpc]

Ping.
Do we agree to do this?

[michaelmaitland]

In D159368#4650810, @wangpc wrote:

Ping.
Do we agree to do this?

I think so. My last comment expresses that there may be some lost opportunity since less instructions hasSEWOp now. The diff in this patch shows that we bail out of some optimizations when !hasSEWOp. I am concerned that the SEW operand we remove from the instructions in this patch may lead to bailing out early, when we still have SEW information. I think we could be doing hasSEWOp() || hasSEWInPseudoName() to guard these optimizations and add something like getSEWFromPseudoName(). WDYT?

[wangpc]

In D159368#4650924, @michaelmaitland wrote:

In D159368#4650810, @wangpc wrote:

Ping.
Do we agree to do this?

I think so. My last comment expresses that there may be some lost opportunity since less instructions hasSEWOp now. The diff in this patch shows that we bail out of some optimizations when !hasSEWOp. I am concerned that the SEW operand we remove from the instructions in this patch may lead to bailing out early, when we still have SEW information. I think we could be doing hasSEWOp() || hasSEWInPseudoName() to guard these optimizations and add something like getSEWFromPseudoName(). WDYT?

IIUC, I think I have done the hasSEWOp() || hasSEWInPseudoName() thing in newly-added RISCVII::hasSEW?