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

[X86][CodeGen] Fix crash when commute operands of Instruction for code size #79245

Merged
merged 3 commits into from
Jan 24, 2024

Conversation

KanRobert
Copy link
Contributor

@KanRobert KanRobert commented Jan 24, 2024

Reported in 134fcc6

Incorrect opcode is used b/c there is a [[fallthrough]] at line 2386.

@llvmbot
Copy link
Collaborator

llvmbot commented Jan 24, 2024

@llvm/pr-subscribers-backend-x86

Author: Shengchen Kan (KanRobert)

Changes

Reported in 134fcc6


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

1 Files Affected:

  • (modified) llvm/lib/Target/X86/X86InstrInfo.cpp (+6-5)
diff --git a/llvm/lib/Target/X86/X86InstrInfo.cpp b/llvm/lib/Target/X86/X86InstrInfo.cpp
index d6f9aa6d6acec09..6cdfecf1fe4d99e 100644
--- a/llvm/lib/Target/X86/X86InstrInfo.cpp
+++ b/llvm/lib/Target/X86/X86InstrInfo.cpp
@@ -2355,29 +2355,30 @@ MachineInstr *X86InstrInfo::commuteInstructionImpl(MachineInstr &MI, bool NewMI,
     // If we're optimizing for size, try to use MOVSD/MOVSS.
     if (MI.getParent()->getParent()->getFunction().hasOptSize()) {
       unsigned Mask;
+      unsigned NewOpc;
       switch (Opc) {
       default:
         llvm_unreachable("Unreachable!");
       case X86::BLENDPDrri:
-        Opc = X86::MOVSDrr;
+        NewOpc = X86::MOVSDrr;
         Mask = 0x03;
         break;
       case X86::BLENDPSrri:
-        Opc = X86::MOVSSrr;
+        NewOpc = X86::MOVSSrr;
         Mask = 0x0F;
         break;
       case X86::VBLENDPDrri:
-        Opc = X86::VMOVSDrr;
+        NewOpc = X86::VMOVSDrr;
         Mask = 0x03;
         break;
       case X86::VBLENDPSrri:
-        Opc = X86::VMOVSSrr;
+        NewOpc = X86::VMOVSSrr;
         Mask = 0x0F;
         break;
       }
       if ((MI.getOperand(3).getImm() ^ Mask) == 1) {
         WorkingMI = CloneIfNew(MI);
-        WorkingMI->setDesc(get(Opc));
+        WorkingMI->setDesc(get(NewOpc));
         WorkingMI->removeOperand(3);
         break;
       }

@KanRobert
Copy link
Contributor Author

Difficult for me to create a test for this, maybe @gulfemsavrun could provide a reproducer later.

@phoebewang
Copy link
Contributor

Difficult for me to create a test for this, maybe @gulfemsavrun could provide a reproducer later.

$ cat tmp.ll
define <4 x float> @foo(<4 x float> %a, <4 x float> %b) optsize {
  %r = shufflevector <4 x float> %b, <4 x float> %a, <4 x i32> <i32 0, i32 5, i32 2, i32 3>
  ret <4 x float> %r
}

$ llc < tmp.ll -mattr=+avx2
        .text
        .file   "<stdin>"
Unreachable!
UNREACHABLE executed at /export/users/pengfeiw/llvm-project/llvm/lib/Target/X86/X86InstrInfo.cpp:2396!

@KanRobert
Copy link
Contributor Author

Difficult for me to create a test for this, maybe @gulfemsavrun could provide a reproducer later.

$ cat tmp.ll
define <4 x float> @foo(<4 x float> %a, <4 x float> %b) optsize {
  %r = shufflevector <4 x float> %b, <4 x float> %a, <4 x i32> <i32 0, i32 5, i32 2, i32 3>
  ret <4 x float> %r
}

$ llc < tmp.ll -mattr=+avx2
        .text
        .file   "<stdin>"
Unreachable!
UNREACHABLE executed at /export/users/pengfeiw/llvm-project/llvm/lib/Target/X86/X86InstrInfo.cpp:2396!

Awesome! Just added.

Copy link

github-actions bot commented Jan 24, 2024

⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️

You can test this locally with the following command:
git-clang-format --diff 71d64ed80f8b7556be6954b2c4d663c7d89f476d ebc5996aba54ff30bef1c6f9af9811cb582ca98c -- llvm/lib/Target/X86/X86InstrInfo.cpp
View the diff from clang-format here.
diff --git a/llvm/lib/Target/X86/X86InstrInfo.cpp b/llvm/lib/Target/X86/X86InstrInfo.cpp
index 975d12d271..7cc9bd9c2e 100644
--- a/llvm/lib/Target/X86/X86InstrInfo.cpp
+++ b/llvm/lib/Target/X86/X86InstrInfo.cpp
@@ -2326,7 +2326,8 @@ MachineInstr *X86InstrInfo::commuteInstructionImpl(MachineInstr &MI, bool NewMI,
   case X86::VBLENDPSrri:
     // If we're optimizing for size, try to use MOVSD/MOVSS.
     if (MI.getParent()->getParent()->getFunction().hasOptSize()) {
-      unsigned Mask = (Opc == X86::BLENDPDrri || Opc == X86::VBLENDPDrri) ? 0x03: 0x0F;
+      unsigned Mask =
+          (Opc == X86::BLENDPDrri || Opc == X86::VBLENDPDrri) ? 0x03 : 0x0F;
       if ((MI.getOperand(3).getImm() ^ Mask) == 1) {
 #define FROM_TO(FROM, TO)                                                      \
   case X86::FROM:                                                              \
@@ -2335,10 +2336,10 @@ MachineInstr *X86InstrInfo::commuteInstructionImpl(MachineInstr &MI, bool NewMI,
         switch (Opc) {
         default:
           llvm_unreachable("Unreachable!");
-        FROM_TO(BLENDPDrri, MOVSDrr)
-        FROM_TO(BLENDPSrri, MOVSSrr)
-        FROM_TO(VBLENDPDrri, VMOVSDrr)
-        FROM_TO(VBLENDPSrri, VMOVSSrr)
+          FROM_TO(BLENDPDrri, MOVSDrr)
+          FROM_TO(BLENDPSrri, MOVSSrr)
+          FROM_TO(VBLENDPDrri, VMOVSDrr)
+          FROM_TO(VBLENDPSrri, VMOVSSrr)
         }
         WorkingMI = CloneIfNew(MI);
         WorkingMI->setDesc(get(Opc));

@RKSimon RKSimon self-requested a review January 24, 2024 08:48
@RKSimon
Copy link
Collaborator

RKSimon commented Jan 24, 2024

For 18.x are we better off reverting 134fcc6 or cherry picking this patch when its completed? For safety I'm currently preferring reversion.

Comment on lines 2331 to 2333
#define FROM_TO(A, B) \
case X86::A: \
Opc = X86::B; \
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit, using FROM, TO to replace A, B

Copy link
Contributor

@phoebewang phoebewang left a comment

Choose a reason for hiding this comment

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

LGTM.

@KanRobert
Copy link
Contributor Author

For 18.x are we better off reverting 134fcc6 or cherry picking this patch when its completed? For safety I'm currently preferring reversion.

I think it would not be a clean revert. I prefer a cherry-pick @RKSimon

@KanRobert KanRobert merged commit 33ecef9 into llvm:main Jan 24, 2024
2 of 4 checks passed
llvmbot pushed a commit to llvmbot/llvm-project that referenced this pull request Jan 24, 2024
…e size (llvm#79245)

Reported in 134fcc6

Incorrect opcode is used  b/c there is a `[[fallthrough]]` at line 2386.

(cherry picked from commit 33ecef9)
@gulfemsavrun
Copy link
Contributor

I confirm that this fixed the issue that I reported in 134fcc6.

tstellar pushed a commit that referenced this pull request Jan 26, 2024
…e size (#79245)

Reported in 134fcc6

Incorrect opcode is used  b/c there is a `[[fallthrough]]` at line 2386.

(cherry picked from commit 33ecef9)
tstellar pushed a commit to tstellar/llvm-project that referenced this pull request Feb 14, 2024
…e size (llvm#79245)

Reported in 134fcc6

Incorrect opcode is used  b/c there is a `[[fallthrough]]` at line 2386.

(cherry picked from commit 33ecef9)
tstellar pushed a commit to tstellar/llvm-project that referenced this pull request Feb 14, 2024
…e size (llvm#79245)

Reported in 134fcc6

Incorrect opcode is used  b/c there is a `[[fallthrough]]` at line 2386.

(cherry picked from commit 33ecef9)
tstellar pushed a commit to tstellar/llvm-project that referenced this pull request Feb 14, 2024
…e size (llvm#79245)

Reported in 134fcc6

Incorrect opcode is used  b/c there is a `[[fallthrough]]` at line 2386.

(cherry picked from commit 33ecef9)
tstellar pushed a commit to tstellar/llvm-project that referenced this pull request Feb 14, 2024
…e size (llvm#79245)

Reported in 134fcc6

Incorrect opcode is used  b/c there is a `[[fallthrough]]` at line 2386.

(cherry picked from commit 33ecef9)
@pointhex pointhex mentioned this pull request May 7, 2024
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.

None yet

5 participants