Skip to content

[X86] getIntImmCostInst - recognise i64 ICMP EQ/NE special cases #142812

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

Merged
merged 3 commits into from
Jun 6, 2025

Conversation

RKSimon
Copy link
Collaborator

@RKSimon RKSimon commented Jun 4, 2025

If the lower 32-bits of a i64 value are known to be zero, then icmp lowering will shift+truncate down to a i32 allowing the immediate to be embedded.

There's a lot more that could be done here to match icmp lowering, but this PR just focuses on known regressions.

Fixes #142513
Fixes #62145

If the lower 32-bits of a i64 value is known to be zero, then icmp lowering will shift+truncate down to a i32 allowing the immediate to be embedded

There's a lot more that could be done here to match x86 icmp lowering, but this PR just focuses on known regressions.

Fixes llvm#142513
Fixes llvm#62145
@llvmbot
Copy link
Member

llvmbot commented Jun 4, 2025

@llvm/pr-subscribers-backend-x86

Author: Simon Pilgrim (RKSimon)

Changes

If the lower 32-bits of a i64 value is known to be zero, then x86 icmp lowering will shift+truncate down to a i32 allowing the immediate to be embedded.

There's a lot more that could be done here to match x86 icmp lowering, but this PR just focuses on known regressions.

Fixes #142513
Fixes #62145


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

3 Files Affected:

  • (modified) llvm/lib/Target/X86/X86TargetTransformInfo.cpp (+9-2)
  • (modified) llvm/test/CodeGen/X86/pr142513.ll (+1-2)
  • (modified) llvm/test/CodeGen/X86/pr62145.ll (+7-12)
diff --git a/llvm/lib/Target/X86/X86TargetTransformInfo.cpp b/llvm/lib/Target/X86/X86TargetTransformInfo.cpp
index 9864adc4dcc95..33c9edd24646b 100644
--- a/llvm/lib/Target/X86/X86TargetTransformInfo.cpp
+++ b/llvm/lib/Target/X86/X86TargetTransformInfo.cpp
@@ -5993,12 +5993,19 @@ InstructionCost X86TTIImpl::getIntImmCostInst(unsigned Opcode, unsigned Idx,
     // This is an imperfect hack to prevent constant hoisting of
     // compares that might be trying to check if a 64-bit value fits in
     // 32-bits. The backend can optimize these cases using a right shift by 32.
-    // Ideally we would check the compare predicate here. There also other
-    // similar immediates the backend can use shifts for.
+    // There are other predicates and immediates the backend can use shifts for.
     if (Idx == 1 && ImmBitWidth == 64) {
       uint64_t ImmVal = Imm.getZExtValue();
       if (ImmVal == 0x100000000ULL || ImmVal == 0xffffffff)
         return TTI::TCC_Free;
+
+      if (auto *Cmp = dyn_cast_or_null<CmpInst>(Inst)) {
+        if (Cmp->isEquality()) {
+          KnownBits Known = computeKnownBits(Cmp->getOperand(0), DL);
+          if (Known.countMinTrailingZeros() >= 32)
+            return TTI::TCC_Free;
+        }
+      }
     }
     ImmIdx = 1;
     break;
diff --git a/llvm/test/CodeGen/X86/pr142513.ll b/llvm/test/CodeGen/X86/pr142513.ll
index 8503c9bada2e8..fe969104fcf5e 100644
--- a/llvm/test/CodeGen/X86/pr142513.ll
+++ b/llvm/test/CodeGen/X86/pr142513.ll
@@ -21,8 +21,7 @@ define i64 @foo(i64 %x) {
 ; X64-NEXT:    cmpl $65509, %edi # imm = 0xFFE5
 ; X64-NEXT:    je .LBB0_1
 ; X64-NEXT:  # %bb.2: # %if.end
-; X64-NEXT:    movabsq $9219572124669181952, %rax # imm = 0x7FF2800000000000
-; X64-NEXT:    addq $3, %rax
+; X64-NEXT:    movabsq $9219572124669181955, %rax # imm = 0x7FF2800000000003
 ; X64-NEXT:    retq
 ; X64-NEXT:  .LBB0_1: # %if.then
 entry:
diff --git a/llvm/test/CodeGen/X86/pr62145.ll b/llvm/test/CodeGen/X86/pr62145.ll
index 509708fb417c4..38208422be6b4 100644
--- a/llvm/test/CodeGen/X86/pr62145.ll
+++ b/llvm/test/CodeGen/X86/pr62145.ll
@@ -5,41 +5,36 @@
 define void @f(i64 %a, i64 %b) nounwind {
 ; X86-LABEL: f:
 ; X86:       # %bb.0: # %entry
-; X86-NEXT:    pushl %ebx
 ; X86-NEXT:    pushl %edi
 ; X86-NEXT:    pushl %esi
 ; X86-NEXT:    movl {{[0-9]+}}(%esp), %esi
 ; X86-NEXT:    movzwl {{[0-9]+}}(%esp), %eax
-; X86-NEXT:    movl $-65536, %ebx # imm = 0xFFFF0000
-; X86-NEXT:    movl $-589824, %edi # imm = 0xFFF70000
+; X86-NEXT:    movl $-65536, %edi # imm = 0xFFFF0000
 ; X86-NEXT:    cmpl $65527, %eax # imm = 0xFFF7
 ; X86-NEXT:    jne .LBB0_2
 ; X86-NEXT:  # %bb.1: # %if.then
 ; X86-NEXT:    calll ext1@PLT
 ; X86-NEXT:  .LBB0_2: # %if.end
 ; X86-NEXT:    calll ext2@PLT
-; X86-NEXT:    andl %ebx, %esi
-; X86-NEXT:    xorl %edi, %esi
+; X86-NEXT:    andl %edi, %esi
+; X86-NEXT:    cmpl $-589824, %esi # imm = 0xFFF70000
 ; X86-NEXT:    jne .LBB0_3
 ; X86-NEXT:  # %bb.4: # %if.then2
 ; X86-NEXT:    popl %esi
 ; X86-NEXT:    popl %edi
-; X86-NEXT:    popl %ebx
 ; X86-NEXT:    jmp ext1@PLT # TAILCALL
 ; X86-NEXT:  .LBB0_3: # %if.end3
 ; X86-NEXT:    popl %esi
 ; X86-NEXT:    popl %edi
-; X86-NEXT:    popl %ebx
 ; X86-NEXT:    retl
 ;
 ; X64-LABEL: f:
 ; X64:       # %bb.0: # %entry
-; X64-NEXT:    pushq %r15
 ; X64-NEXT:    pushq %r14
 ; X64-NEXT:    pushq %rbx
+; X64-NEXT:    pushq %rax
 ; X64-NEXT:    movq %rsi, %rbx
 ; X64-NEXT:    movabsq $-281474976710656, %r14 # imm = 0xFFFF000000000000
-; X64-NEXT:    movabsq $-2533274790395904, %r15 # imm = 0xFFF7000000000000
 ; X64-NEXT:    shrq $48, %rdi
 ; X64-NEXT:    cmpl $65527, %edi # imm = 0xFFF7
 ; X64-NEXT:    jne .LBB0_2
@@ -48,17 +43,17 @@ define void @f(i64 %a, i64 %b) nounwind {
 ; X64-NEXT:  .LBB0_2: # %if.end
 ; X64-NEXT:    callq ext2@PLT
 ; X64-NEXT:    andq %r14, %rbx
-; X64-NEXT:    cmpq %r15, %rbx
+; X64-NEXT:    movabsq $-2533274790395904, %rax # imm = 0xFFF7000000000000
+; X64-NEXT:    addq $8, %rsp
+; X64-NEXT:    cmpq %rax, %rbx
 ; X64-NEXT:    jne .LBB0_3
 ; X64-NEXT:  # %bb.4: # %if.then2
 ; X64-NEXT:    popq %rbx
 ; X64-NEXT:    popq %r14
-; X64-NEXT:    popq %r15
 ; X64-NEXT:    jmp ext1@PLT # TAILCALL
 ; X64-NEXT:  .LBB0_3: # %if.end3
 ; X64-NEXT:    popq %rbx
 ; X64-NEXT:    popq %r14
-; X64-NEXT:    popq %r15
 ; X64-NEXT:    retq
 entry:
   %shr.mask.i = and i64 %a, -281474976710656

; X86-NEXT: pushl %edi
; X86-NEXT: pushl %esi
; X86-NEXT: movl {{[0-9]+}}(%esp), %esi
; X86-NEXT: movzwl {{[0-9]+}}(%esp), %eax
; X86-NEXT: movl $-65536, %ebx # imm = 0xFFFF0000
; X86-NEXT: movl $-589824, %edi # imm = 0xFFF70000
; X86-NEXT: movl $-65536, %edi # imm = 0xFFFF0000
Copy link
Contributor

Choose a reason for hiding this comment

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

This only has 16 trailing zeros. How it's affected?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

ConstantHoisting occurs before DAG+legalisation as a pre-codegen pass, where its still a i64

@@ -48,17 +43,17 @@ define void @f(i64 %a, i64 %b) nounwind {
; X64-NEXT: .LBB0_2: # %if.end
; X64-NEXT: callq ext2@PLT
; X64-NEXT: andq %r14, %rbx
; X64-NEXT: cmpq %r15, %rbx
; X64-NEXT: movabsq $-2533274790395904, %rax # imm = 0xFFF7000000000000
Copy link
Contributor

Choose a reason for hiding this comment

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

Both code and test changes look good. But I don't understand the logic. we don't compare 0xFFF7000000000000 and the sink is good no matter it has 32 trailing zeros or not.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

this one is annoying - it now stops the hoist because the other icmp using -2533274790395904 is correctly recognized as simplifying to srl+icmp_i32 - but for this one, at DAG stage per-block valuetracking can't tell %shr.mask.i4 is zero in the lower bits (because the -281474976710656 mask is still hoisted), so it still performs the icmp_i64.

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.

@RKSimon RKSimon merged commit f59742c into llvm:main Jun 6, 2025
7 checks passed
@RKSimon RKSimon deleted the x86-immcost-icmp-eq64 branch June 6, 2025 09:21
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.

[X86] 64-bit constant compiled to movabs+add after branch Inefficient codegen for checking top bits of a 64-bit integer
3 participants