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?

Ping.
Do we agree to do this?

Ping.
Are there any more concerns? @jrtc27 @asb

Remove nonnull and inbounds.

• Rebase.
• Don't optimize for constraint A.

• Rebase.
• Address comments.
• Add ReleaseNotes.

We may not need this.

Ping.

Ping.

Rename sew_div_8 to sewDividedBy8.

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?

Rebase and do some refactors.

LGTM.

Resolved all issues.

Closed as I want to use this patch to be familiar with Github workflow(https://github.com/llvm/llvm-project/pull/65292).
Thanks all!

Oops, we should have fixed it in D124431. Sorry @Jim, I didn't know it.

In D158568#4636688, @fpetrogalli wrote:

In D158568#4623906, @wangpc wrote:

Is there any example show how AcquireAtCycles can be used to model scheduling? It's all 0s by default? I don't really understand how it works. :-)

You can watch the talk that describes what StartAtCycle (which became AcquireAtCycle) is for: https://www.youtube.com/watch?v=XWBVLcdzmFg

In D70401#4635875, @koute wrote:

I know that there are still open issues regarding the psABI, but considering how slow it's been going, couldn't we merge this in anyway and mark it as experimental and subject to change? Please?

The patch is simple enough to not become a maintenance burden, and GCC already has it even though the ABI's unfinished, and the RV32E target itself is most likely going to be used for standalone bare metal programs where the exact ABI shouldn't matter too much as long as it works.

I'm asking because I'd really like to have this merged so that I could use Rust to target RV32E/RV64E. Right now I have to maintain my own toolchain, which is painful; if this got merged (even in an experimental fashion, like GCC has) I could just get upstream Rust to support it out-of-box.

In D159333#4634877, @craig.topper wrote:

In D159333#4634843, @wangpc wrote:

In D159333#4634580, @craig.topper wrote:

In D159333#4634476, @wangpc wrote:

In D159333#4633456, @craig.topper wrote:

In D159333#4633394, @wangpc wrote:

In D159333#4633363, @craig.topper wrote:

In D159333#4633354, @wangpc wrote:

In D159333#4633304, @michaelmaitland wrote:

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?

In D159333#4634580, @craig.topper wrote:

In D159333#4634476, @wangpc wrote:

In D159333#4633456, @craig.topper wrote:

In D159333#4633394, @wangpc wrote:

In D159333#4633363, @craig.topper wrote:

In D159333#4633354, @wangpc wrote:

In D159333#4633304, @michaelmaitland wrote:

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).

In D159333#4633456, @craig.topper wrote:

In D159333#4633394, @wangpc wrote:

In D159333#4633363, @craig.topper wrote:

In D159333#4633354, @wangpc wrote:

In D159333#4633304, @michaelmaitland wrote:

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?

In D159333#4633363, @craig.topper wrote:

In D159333#4633354, @wangpc wrote:

In D159333#4633304, @michaelmaitland wrote:

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.

In D159333#4633304, @michaelmaitland wrote:

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.

LGTM, it seems reasonable to me, but please wait for @craig.topper to see if there are more comments.

It seems reasonable to me.
LGTM.

Ping. Is it OK now?

LGTM.

I was thinking about adding v1i256, v1i512, etc. Is it feasible?

LGTM.

LGTM.

In D112921#4624674, @aaron.ballman wrote:

Because the issues have been ongoing for a few hours now, I think it'd make sense to revert these changes while trying to determine what the appropriate fix is. @wangpc would you mind doing the revert?

In D112921#4624141, @nikic wrote:

FYI this resulted in some pretty wild code size swings, in particular between -10% and -15% for tramp3d-v4 (http://llvm-compile-time-tracker.com/compare.php?from=6cde64a94986165547ae5237ac7dd4bddfc9f2a7&to=2916b125f686115deab2ba573dcaff3847566ab9&stat=size-text). Not sure whether that's an expected result of this change or not.

In D112921#4624547, @jhuber6 wrote:

This caused some linking errors with the GPU libc test suite, see https://lab.llvm.org/staging/#/builders/247/builds/5659.

clang++: error: ld.lld command failed with exit code 1 (use -v to see invocation)
[331/473] Linking CXX executable libc/test/src/__support/libc.test.src.__support.uint_test.__hermetic__.__build__
FAILED: libc/test/src/__support/libc.test.src.__support.uint_test.__hermetic__.__build__ 
: && /home/ompworker/bbot/openmp-offload-libc-amdgpu-runtime/llvm.build/./bin/clang++ --target=x86_64-unknown-linux-gnu -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG -Wl,--color-diagnostics    -nostdlib -static libc/startup/gpu/amdgpu/CMakeFiles/libc.startup.gpu.amdgpu.crt1.dir/start.cpp.o libc/test/src/__support/CMakeFiles/libc.test.src.__support.uint_test.__hermetic__.__build__.dir/uint_test.cpp.o -o libc/test/src/__support/libc.test.src.__support.uint_test.__hermetic__.__build__  libc/test/UnitTest/libLibcTest.hermetic.a  libc/test/UnitTest/libLibcHermeticTestSupport.hermetic.a  libc/test/src/__support/liblibc.test.src.__support.uint_test.__hermetic__.libc.a  -mcpu=gfx906  --target=amdgcn-amd-amdhsa  -flto  -Wl,-mllvm,-amdgpu-lower-global-ctor-dtor=0 && :
ld.lld: error: undefined symbol: operator delete(void*, unsigned long)
>>> referenced by lto.tmp:(LlvmLibcUIntClassTest_ConstructorFromUInt128Tests::~LlvmLibcUIntClassTest_ConstructorFromUInt128Tests())
>>> referenced by lto.tmp:(LlvmLibcUIntClassTest_ConstructorFromUInt128Tests::~LlvmLibcUIntClassTest_ConstructorFromUInt128Tests())
>>> referenced by lto.tmp:(LlvmLibcUIntClassTest_BasicArithmeticInt128Tests::~LlvmLibcUIntClassTest_BasicArithmeticInt128Tests())
>>> referenced 41 more times
>>> did you mean: operator delete(void*)
>>> defined in: lto.tmp
clang++: error: ld.lld command failed with exit code 1 (use -v to see invocation)

In D112921#4624488, @thakis wrote:

Looks like this breaks tests on windows: http://45.33.8.238/win/83485/step_7.txt

Please take a look and revert for now if it takes a while to fix.

(Also, if the patch doesn't already do it, it probably shouldn't change defaults in clang-cl mode?)

Thanks all! I will land this patch later.
If there are some failures (especially libcxx part @Mordante :-) ), please help me to fix them. Thanks in advance!

Rebase.

Is there any example show how AcquireAtCycles can be used to model scheduling? It's all 0s by default? I don't really understand how it works. :-)

Exclude PseudoVMANDN and PseudoVMORN.

LGTM.

Gentle ping. :-)

I remember that the reasom why we added separate Scheds for min/max reductions is that your downstream needs to give different scheduling for min/max from other reductions in D155108.
Is it right for this processor?

In D158976#4621291, @michaelmaitland wrote:

I'm not very familiar with how isCommutable works, but this change looks like a good idea as long as isCommutable only refers to the $rs2 and $rs1 operands, and does not say anything about commutability of $carry, $vl, or $sew.

In D112921#4621019, @aaron.ballman wrote:

In D112921#4620399, @wangpc wrote:

Gentle ping. Can I move forward and land this?

What name and email address would you like us to use for patch attribution?

Thanks! I have commit access.

Gentle ping. Can I move forward and land this?

FYI: I think D157694 is related.

Rebase and address comments.

Rebase.

Ping.