Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RISCV][VLOPT] Add support for more instructions in vl-opt-op-info.mir #119416

Merged
merged 6 commits into from
Dec 17, 2024

Conversation

michaelmaitland
Copy link
Contributor

@michaelmaitland michaelmaitland commented Dec 10, 2024

Specifically, add ones where EMUL=LMUL and EEW=SEW.

@llvmbot
Copy link
Member

llvmbot commented Dec 10, 2024

@llvm/pr-subscribers-backend-risc-v

Author: Michael Maitland (michaelmaitland)

Changes

Full diff: https://github.com/llvm/llvm-project/pull/119416.diff

1 Files Affected:

  • (modified) llvm/test/CodeGen/RISCV/rvv/vl-opt-op-info.mir (+30)
diff --git a/llvm/test/CodeGen/RISCV/rvv/vl-opt-op-info.mir b/llvm/test/CodeGen/RISCV/rvv/vl-opt-op-info.mir
index 1071ee53610854..32c5bf2f12e22f 100644
--- a/llvm/test/CodeGen/RISCV/rvv/vl-opt-op-info.mir
+++ b/llvm/test/CodeGen/RISCV/rvv/vl-opt-op-info.mir
@@ -1,6 +1,36 @@
 # NOTE: Assertions have been autogenerated by utils/update_mir_test_checks.py UTC_ARGS: --version 5
 # RUN: llc %s -o - -mtriple=riscv64 -mattr=+v -run-pass=riscv-vl-optimizer -verify-machineinstrs | FileCheck %s
 
+---
+name: vop_vi
+body: |
+  bb.0:
+    ; CHECK-LABEL: name: vop_vi
+    ; CHECK: %x:vr = PseudoVADD_VI_M1 $noreg, $noreg, 9, 1, 3 /* e8 */, 0 /* tu, mu */
+    ; CHECK-NEXT: %y:vr = PseudoVADD_VI_M1 $noreg, %x, 9, 1, 3 /* e8 */, 0 /* tu, mu */
+    %x:vr = PseudoVADD_VI_M1 $noreg, $noreg, 9, -1, 3 /* e8 */, 0
+    %y:vr = PseudoVADD_VI_M1 $noreg, %x, 9, 1, 3 /* e8 */, 0
+...
+---
+name: vop_vi_incompatible_eew
+body: |
+  bb.0:
+    ; CHECK-LABEL: name: vop_vi_incompatible_eew
+    ; CHECK: %x:vr = PseudoVADD_VI_M1 $noreg, $noreg, 9, -1, 3 /* e8 */, 0 /* tu, mu */
+    ; CHECK-NEXT: %y:vr = PseudoVADD_VI_M1 $noreg, %x, 9, 1, 4 /* e16 */, 0 /* tu, mu */
+    %x:vr = PseudoVADD_VI_M1 $noreg, $noreg, 9, -1, 3 /* e8 */, 0
+    %y:vr = PseudoVADD_VI_M1 $noreg, %x, 9, 1, 4 /* e16 */, 0
+...
+---
+name: vop_vi_incompatible_emul
+body: |
+  bb.0:
+    ; CHECK-LABEL: name: vop_vi_incompatible_emul
+    ; CHECK: %x:vr = PseudoVADD_VI_M1 $noreg, $noreg, 9, -1, 3 /* e8 */, 0 /* tu, mu */
+    ; CHECK-NEXT: %y:vr = PseudoVADD_VI_MF2 $noreg, %x, 9, 1, 3 /* e8 */, 0 /* tu, mu */
+    %x:vr = PseudoVADD_VI_M1 $noreg, $noreg, 9, -1, 3 /* e8 */, 0
+    %y:vr = PseudoVADD_VI_MF2 $noreg, %x, 9, 1, 3 /* e8 */, 0
+...
 ---
 name: vop_vv
 body: |

@michaelmaitland michaelmaitland changed the title [RISCV][VLOPT] Add support for vop_vi style instructions in vl-opt-op-info.mir [RISCV][VLOPT] Add support for vop_vi and vmerge in vl-opt-op-info.mir Dec 10, 2024
@michaelmaitland michaelmaitland changed the title [RISCV][VLOPT] Add support for vop_vi and vmerge in vl-opt-op-info.mir [RISCV][VLOPT] Add support for more SEW=EEW EMUL=EEW instructions in vl-opt-op-info.mir Dec 10, 2024
@michaelmaitland michaelmaitland force-pushed the vop-vi-vlopt branch 3 times, most recently from c7fbec8 to 811fd1b Compare December 10, 2024 17:53
@topperc
Copy link
Collaborator

topperc commented Dec 10, 2024

EMUL=EEW in the title doesn't make sense.

@michaelmaitland michaelmaitland changed the title [RISCV][VLOPT] Add support for more SEW=EEW EMUL=EEW instructions in vl-opt-op-info.mir [RISCV][VLOPT] Add support for more instructions in vl-opt-op-info.mir Dec 10, 2024
@michaelmaitland
Copy link
Contributor Author

EMUL=EEW in the title doesn't make sense.

Updated

; CHECK: %x:vr = PseudoVADD_VV_M1 $noreg, $noreg, $noreg, 1, 3 /* e8 */, 0 /* tu, mu */
; CHECK-NEXT: %y:vr = PseudoVMV_V_I_M1 $noreg, %x, 1, 3 /* e8 */, 0 /* tu, mu */
%x:vr = PseudoVADD_VV_M1 $noreg, $noreg, $noreg, -1, 3 /* e8 */, 0
%y:vr = PseudoVMV_V_I_M1 $noreg, %x, 1, 3 /* e8 */, 0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be VMV_V_V_M1?

; CHECK: %x:vr = PseudoVADD_VV_M1 $noreg, $noreg, $noreg, -1, 4 /* e16 */, 0 /* tu, mu */
; CHECK-NEXT: %y:vr = PseudoVMV_V_V_M1 %x, $noreg, 1, 4 /* e16 */, 0 /* tu, mu */
%x:vr = PseudoVADD_VV_M1 $noreg, $noreg, $noreg, -1, 4 /* e16 */, 0
%y:vr = PseudoVMV_V_V_M1 %x, $noreg, 1, 4 /* e16 */, 0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is testing the pasthru operand which can never fold regardless of the EEW being incompatible

michaelmaitland added a commit to michaelmaitland/llvm-project that referenced this pull request Dec 10, 2024
Now that we have testing of all instructions in the isSupportedInstr switch,
and better coverage of getOperandInfo, I think it is a good time to enable this
by default.

I'd like for llvm#112231 and
llvm#119416 to land before this patch,
so it'd be great for anyone reviewing this to check those out first.
Copy link
Contributor

@lukel97 lukel97 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The existing vop_vv_* test cases should cover the EEW=SEW EMUL=EMUL format instructions.

I think the original structure of this test was to test the various formats/combinations of EEW and EMUL, but with that said I'm not opposed if we want to test specific opcodes either

@michaelmaitland
Copy link
Contributor Author

The existing vop_vv_* test cases should cover the EEW=SEW EMUL=EMUL format instructions.

I think the original structure of this test was to test the various formats/combinations of EEW and EMUL, but with that said I'm not opposed if we want to test specific opcodes either

While its true that we cover the return statements in getOperandInfo already, this patch adds some tests for instructions that definitely have different properties than whats currently being tested. Just because an instruction is grouped up with a common return statement, it doesn't mean that it actually belongs there. I'd like to build this test up over time to get increased confidence that instructions grouped under a common return statement actually belong there.

; CHECK-NEXT: %z:vr = PseudoVMV_V_X_M1 %x, %y, 1, 4 /* e16 */, 0 /* tu, mu */
%x:vr = PseudoVADD_VV_M1 $noreg, $noreg, $noreg, -1, 4 /* e16 */, 0
%y:gpr = ADDI $x0, 1
%z:vr = PseudoVMV_V_X_M1 %x, %y, 1, 4 /* e16 */, 0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are the EEWs here not compatible?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for typo. Fixed.

; CHECK-LABEL: name: vop_vi
; CHECK: %x:vr = PseudoVADD_VI_M1 $noreg, $noreg, 9, 1, 3 /* e8 */, 0 /* tu, mu */
; CHECK-NEXT: %y:vr = PseudoVADD_VI_M1 $noreg, %x, 9, 1, 3 /* e8 */, 0 /* tu, mu */
%x:vr = PseudoVADD_VI_M1 $noreg, $noreg, 9, -1, 3 /* e8 */, 0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit, can we keep the instruction not under test VADD_VV to make it easier to tell which operand info we should be looking out for?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@lukel97
Copy link
Contributor

lukel97 commented Dec 11, 2024

The existing vop_vv_* test cases should cover the EEW=SEW EMUL=EMUL format instructions.

I think the original structure of this test was to test the various formats/combinations of EEW and EMUL, but with that said I'm not opposed if we want to test specific opcodes either

While its true that we cover the return statements in getOperandInfo already, this patch adds some tests for instructions that definitely have different properties than whats currently being tested. Just because an instruction is grouped up with a common return statement, it doesn't mean that it actually belongs there. I'd like to build this test up over time to get increased confidence that instructions grouped under a common return statement actually belong there.

That sounds reasonable to me

@michaelmaitland
Copy link
Contributor Author

ping

michaelmaitland added a commit to michaelmaitland/llvm-project that referenced this pull request Dec 17, 2024
Now that we have testing of all instructions in the isSupportedInstr switch,
and better coverage of getOperandInfo, I think it is a good time to enable this
by default.

I'd like for llvm#112231 and
llvm#119416 to land before this patch,
so it'd be great for anyone reviewing this to check those out first.
Copy link
Collaborator

@topperc topperc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@michaelmaitland michaelmaitland merged commit 904849f into llvm:main Dec 17, 2024
8 checks passed
@michaelmaitland michaelmaitland deleted the vop-vi-vlopt branch December 17, 2024 17:57
@llvm-ci
Copy link
Collaborator

llvm-ci commented Dec 17, 2024

LLVM Buildbot has detected a new failure on builder cross-project-tests-sie-ubuntu running on doug-worker-1a while building llvm at step 2 "checkout".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/181/builds/10519

Here is the relevant piece of the build log for the reference
Step 2 (checkout) failure: update (failure)
git version 2.25.1
fatal: unable to access 'https://github.com/llvm/llvm-project.git/': HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8)
fatal: unable to access 'https://github.com/llvm/llvm-project.git/': HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants