This is an archive of the discontinued LLVM Phabricator instance.

[RISCV] Replace RISCVVInversePseudosTable with a SearchIndex
AbandonedPublic

Authored by wangpc on Aug 31 2023, 9:05 PM.

Details

Summary

The contents of RISCVVInversePseudosTable and RISCVVPseudosTable
are reduplicative. We can only generate one table with all info
we need and search it by a SearchIndex.

I was hoping that this change can reduce generated file but the diff
seems to be little(only about 10 lines are reduced), because reversed
search table will be generated for SearchIndex.

This patch also puts RISCVVPseudosTable back to RISCVBaseInfo so
that MCA part won't depend on RISCVCodeGen component.

Diff Detail

Event Timeline

wangpc created this revision.Aug 31 2023, 9:05 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 31 2023, 9:05 PM
wangpc requested review of this revision.Aug 31 2023, 9:05 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 31 2023, 9:05 PM

It looks like the InversePseudo table was only included for MCA directory. I wonder if this led to it only being a part of the llvm-mca binary, and not part of tools that do not depend on llvm-mca (such as llc). Could you check this by comparing the size of llc binary? It should have gotten larger after this change if it had not previously included the InversePseudo table.

wangpc added a comment.EditedAug 31 2023, 10:25 PM

It looks like the InversePseudo table was only included for MCA directory. I wonder if this led to it only being a part of the llvm-mca binary, and not part of tools that do not depend on llvm-mca (such as llc). Could you check this by comparing the size of llc binary? It should have gotten larger after this change if it had not previously included the InversePseudo table.

Yes, the size will increase about 100KB for llc.
My intention is to unify the table (and make the code more consistent?). And if we can get SEW of pseudos from this table, then we don't need to specify the explict SEW imm in pseudos' operands (WIP).
For example:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl, ixlenimm:$sew,
                  ixlenimm:$policy), []>

becomes:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl,
                  ixlenimm:$policy), []>,

This may simplify the generated patterns I think.

It looks like the InversePseudo table was only included for MCA directory. I wonder if this led to it only being a part of the llvm-mca binary, and not part of tools that do not depend on llvm-mca (such as llc). Could you check this by comparing the size of llc binary? It should have gotten larger after this change if it had not previously included the InversePseudo table.

Yes, the size will increase about 100KB for llc.
My intention is to unify the table (and make the code more consistent?). And if we can get SEW of pseudos from this table, then we don't need to specify the explict SEW imm in pseudos' operands (WIP).
For example:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl, ixlenimm:$sew,
                  ixlenimm:$policy), []>

becomes:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl,
                  ixlenimm:$policy), []>,

This may simplify the generated patterns I think.

Won't that require adding more pseudos for each SEW. Many pseudos don't have SEW today.

wangpc added a comment.EditedAug 31 2023, 10:50 PM

It looks like the InversePseudo table was only included for MCA directory. I wonder if this led to it only being a part of the llvm-mca binary, and not part of tools that do not depend on llvm-mca (such as llc). Could you check this by comparing the size of llc binary? It should have gotten larger after this change if it had not previously included the InversePseudo table.

Yes, the size will increase about 100KB for llc.
My intention is to unify the table (and make the code more consistent?). And if we can get SEW of pseudos from this table, then we don't need to specify the explict SEW imm in pseudos' operands (WIP).
For example:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl, ixlenimm:$sew,
                  ixlenimm:$policy), []>

becomes:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl,
                  ixlenimm:$policy), []>,

This may simplify the generated patterns I think.

Won't that require adding more pseudos for each SEW. Many pseudos don't have SEW today.

I think almost all pseudos has HasSEWOp being true?
Edit: I get it. I won't add more pseduos, but remove the SEW operand for existed pseudos.

It looks like the InversePseudo table was only included for MCA directory. I wonder if this led to it only being a part of the llvm-mca binary, and not part of tools that do not depend on llvm-mca (such as llc). Could you check this by comparing the size of llc binary? It should have gotten larger after this change if it had not previously included the InversePseudo table.

Yes, the size will increase about 100KB for llc.
My intention is to unify the table (and make the code more consistent?). And if we can get SEW of pseudos from this table, then we don't need to specify the explict SEW imm in pseudos' operands (WIP).
For example:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl, ixlenimm:$sew,
                  ixlenimm:$policy), []>

becomes:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl,
                  ixlenimm:$policy), []>,

This may simplify the generated patterns I think.

Won't that require adding more pseudos for each SEW. Many pseudos don't have SEW today.

I think almost all pseudos has HasSEWOp being true?
Edit: I get it. I won't add more pseduos, but remove the SEW operand for existed pseudos.

So there will 2 kinds of pseudos? Those with SEW in their name and those with an SEW operand?

wangpc added a comment.Sep 1 2023, 8:45 AM

It looks like the InversePseudo table was only included for MCA directory. I wonder if this led to it only being a part of the llvm-mca binary, and not part of tools that do not depend on llvm-mca (such as llc). Could you check this by comparing the size of llc binary? It should have gotten larger after this change if it had not previously included the InversePseudo table.

Yes, the size will increase about 100KB for llc.
My intention is to unify the table (and make the code more consistent?). And if we can get SEW of pseudos from this table, then we don't need to specify the explict SEW imm in pseudos' operands (WIP).
For example:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl, ixlenimm:$sew,
                  ixlenimm:$policy), []>

becomes:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl,
                  ixlenimm:$policy), []>,

This may simplify the generated patterns I think.

Won't that require adding more pseudos for each SEW. Many pseudos don't have SEW today.

I think almost all pseudos has HasSEWOp being true?
Edit: I get it. I won't add more pseduos, but remove the SEW operand for existed pseudos.

So there will 2 kinds of pseudos? Those with SEW in their name and those with an SEW operand?

Yes.
I just tried, if we remove the SEW operand of SEW-aware pseudos (load/store instructions are excluded in my experiment currently) operands and search SEW by RISCVVPseudosTable, we can reduce 30K of llc's text section and about 6000 lines of RISCVGenDAGISel.inc. But it will also add some complexities and make the RVV pseudos inconsistent.
I may post the patch after more investigations next week.

It looks like the InversePseudo table was only included for MCA directory. I wonder if this led to it only being a part of the llvm-mca binary, and not part of tools that do not depend on llvm-mca (such as llc). Could you check this by comparing the size of llc binary? It should have gotten larger after this change if it had not previously included the InversePseudo table.

Yes, the size will increase about 100KB for llc.
My intention is to unify the table (and make the code more consistent?). And if we can get SEW of pseudos from this table, then we don't need to specify the explict SEW imm in pseudos' operands (WIP).
For example:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl, ixlenimm:$sew,
                  ixlenimm:$policy), []>

becomes:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl,
                  ixlenimm:$policy), []>,

This may simplify the generated patterns I think.

Won't that require adding more pseudos for each SEW. Many pseudos don't have SEW today.

I think almost all pseudos has HasSEWOp being true?
Edit: I get it. I won't add more pseduos, but remove the SEW operand for existed pseudos.

So there will 2 kinds of pseudos? Those with SEW in their name and those with an SEW operand?

Yes.
I just tried, if we remove the SEW operand of SEW-aware pseudos (load/store instructions are excluded in my experiment currently) operands and search SEW by RISCVVPseudosTable, we can reduce 30K of llc's text section and about 6000 lines of RISCVGenDAGISel.inc. But it will also add some complexities and make the RVV pseudos inconsistent.
I may post the patch after more investigations next week.

Where does the 30K text section reduction come from? What code are we reducing?

There should be a comment in RISCVGenDAGISel.inc that says "Total Array size is" can give the reduction on that value. That's more interesting than lines.

wangpc added a comment.EditedSep 1 2023, 10:32 AM

It looks like the InversePseudo table was only included for MCA directory. I wonder if this led to it only being a part of the llvm-mca binary, and not part of tools that do not depend on llvm-mca (such as llc). Could you check this by comparing the size of llc binary? It should have gotten larger after this change if it had not previously included the InversePseudo table.

Yes, the size will increase about 100KB for llc.
My intention is to unify the table (and make the code more consistent?). And if we can get SEW of pseudos from this table, then we don't need to specify the explict SEW imm in pseudos' operands (WIP).
For example:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl, ixlenimm:$sew,
                  ixlenimm:$policy), []>

becomes:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl,
                  ixlenimm:$policy), []>,

This may simplify the generated patterns I think.

Won't that require adding more pseudos for each SEW. Many pseudos don't have SEW today.

I think almost all pseudos has HasSEWOp being true?
Edit: I get it. I won't add more pseduos, but remove the SEW operand for existed pseudos.

So there will 2 kinds of pseudos? Those with SEW in their name and those with an SEW operand?

Yes.
I just tried, if we remove the SEW operand of SEW-aware pseudos (load/store instructions are excluded in my experiment currently) operands and search SEW by RISCVVPseudosTable, we can reduce 30K of llc's text section and about 6000 lines of RISCVGenDAGISel.inc. But it will also add some complexities and make the RVV pseudos inconsistent.
I may post the patch after more investigations next week.

Posted in D159368.

Where does the 30K text section reduction come from? What code are we reducing?

There should be a comment in RISCVGenDAGISel.inc that says "Total Array size is" can give the reduction on that value. That's more interesting than lines.

Because we don't need to match and add SEW operand, the size of MatcherTable can be reduced by about 23000 bytes, I think most of the reduction comes from here. RISCVGenInstrInfo has some reductions too.
My proposal is removing SEW operand of load/store instructions and SEW-aware instrucitons like reductions, div, sqrt, etc. And the SEW value can be searched by RISCVVPseudosTable (or, we can encode it in TSFlags like LMUL by using 2bits).

It looks like the InversePseudo table was only included for MCA directory. I wonder if this led to it only being a part of the llvm-mca binary, and not part of tools that do not depend on llvm-mca (such as llc). Could you check this by comparing the size of llc binary? It should have gotten larger after this change if it had not previously included the InversePseudo table.

Yes, the size will increase about 100KB for llc.
My intention is to unify the table (and make the code more consistent?). And if we can get SEW of pseudos from this table, then we don't need to specify the explict SEW imm in pseudos' operands (WIP).
For example:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl, ixlenimm:$sew,
                  ixlenimm:$policy), []>

becomes:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl,
                  ixlenimm:$policy), []>,

This may simplify the generated patterns I think.

Won't that require adding more pseudos for each SEW. Many pseudos don't have SEW today.

I think almost all pseudos has HasSEWOp being true?
Edit: I get it. I won't add more pseduos, but remove the SEW operand for existed pseudos.

So there will 2 kinds of pseudos? Those with SEW in their name and those with an SEW operand?

Yes.
I just tried, if we remove the SEW operand of SEW-aware pseudos (load/store instructions are excluded in my experiment currently) operands and search SEW by RISCVVPseudosTable, we can reduce 30K of llc's text section and about 6000 lines of RISCVGenDAGISel.inc. But it will also add some complexities and make the RVV pseudos inconsistent.
I may post the patch after more investigations next week.

Posted in D159368.

Where does the 30K text section reduction come from? What code are we reducing?

There should be a comment in RISCVGenDAGISel.inc that says "Total Array size is" can give the reduction on that value. That's more interesting than lines.

Because we don't need to match and add SEW operand, the size of MatcherTable can be reduced by about 23000 bytes, I think most of the reduction comes from here. RISCVGenInstrInfo has some reductions too.
My proposal is removing SEW operand of load/store instructions and SEW-aware instrucitons like reductions, div, sqrt, etc. And the SEW value can searched by RISCVVPseudosTable (or, we can encode it in TSFlags like LMUL by using 2bits).

Is the matcher table in the .text section?

It looks like the InversePseudo table was only included for MCA directory. I wonder if this led to it only being a part of the llvm-mca binary, and not part of tools that do not depend on llvm-mca (such as llc). Could you check this by comparing the size of llc binary? It should have gotten larger after this change if it had not previously included the InversePseudo table.

Yes, the size will increase about 100KB for llc.
My intention is to unify the table (and make the code more consistent?). And if we can get SEW of pseudos from this table, then we don't need to specify the explict SEW imm in pseudos' operands (WIP).
For example:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl, ixlenimm:$sew,
                  ixlenimm:$policy), []>

becomes:

class VPseudoUSLoadNoMask<VReg RetClass,
                          int EEW> :
      Pseudo<(outs RetClass:$rd),
             (ins RetClass:$dest, GPRMem:$rs1, AVL:$vl,
                  ixlenimm:$policy), []>,

This may simplify the generated patterns I think.

Won't that require adding more pseudos for each SEW. Many pseudos don't have SEW today.

I think almost all pseudos has HasSEWOp being true?
Edit: I get it. I won't add more pseduos, but remove the SEW operand for existed pseudos.

So there will 2 kinds of pseudos? Those with SEW in their name and those with an SEW operand?

Yes.
I just tried, if we remove the SEW operand of SEW-aware pseudos (load/store instructions are excluded in my experiment currently) operands and search SEW by RISCVVPseudosTable, we can reduce 30K of llc's text section and about 6000 lines of RISCVGenDAGISel.inc. But it will also add some complexities and make the RVV pseudos inconsistent.
I may post the patch after more investigations next week.

Posted in D159368.

Where does the 30K text section reduction come from? What code are we reducing?

There should be a comment in RISCVGenDAGISel.inc that says "Total Array size is" can give the reduction on that value. That's more interesting than lines.

Because we don't need to match and add SEW operand, the size of MatcherTable can be reduced by about 23000 bytes, I think most of the reduction comes from here. RISCVGenInstrInfo has some reductions too.
My proposal is removing SEW operand of load/store instructions and SEW-aware instrucitons like reductions, div, sqrt, etc. And the SEW value can searched by RISCVVPseudosTable (or, we can encode it in TSFlags like LMUL by using 2bits).

Is the matcher table in the .text section?

I am curious about it too because it should be in .data I think, but I only saw text diff when using size llc.

wangpc planned changes to this revision.Sep 11 2023, 11:16 PM

We may not need this.

wangpc abandoned this revision.Oct 29 2023, 9:16 PM