[X86] Correct 32-bit immediate assertion and fix 64-bit lowering for huge frame offsets #123872

wesleywiser · 2025-01-22T03:51:51Z

The assertion previously did not work correctly because the operand was being truncated to an int prior to comparison.

Change the assertion into a a reported error as suggested in #101840 (comment) by @arsenm

Finally, fix the lowering on 64-bit targets so that offsets larger than 32-bit are correctly addressed and add tests for various reported issues.

llvmbot · 2025-01-22T03:52:25Z

@llvm/pr-subscribers-backend-x86

Author: Wesley Wiser (wesleywiser)

Changes

The assertion previously did not work correctly because the operand was being truncated to an int prior to comparison.

Change the assertion into a a reported error as suggested in #101840 (comment) by @arsenm

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

1 Files Affected:

(modified) llvm/lib/Target/X86/X86RegisterInfo.cpp (+4-5)

diff --git a/llvm/lib/Target/X86/X86RegisterInfo.cpp b/llvm/lib/Target/X86/X86RegisterInfo.cpp
index 4faf8bca4f9e02..8a35de5ca98f11 100644
--- a/llvm/lib/Target/X86/X86RegisterInfo.cpp
+++ b/llvm/lib/Target/X86/X86RegisterInfo.cpp
@@ -965,11 +965,10 @@ X86RegisterInfo::eliminateFrameIndex(MachineBasicBlock::iterator II,
   }
 
   if (MI.getOperand(FIOperandNum+3).isImm()) {
-    // Offset is a 32-bit integer.
-    int Imm = (int)(MI.getOperand(FIOperandNum + 3).getImm());
-    int Offset = FIOffset + Imm;
-    assert((!Is64Bit || isInt<32>((long long)FIOffset + Imm)) &&
-           "Requesting 64-bit offset in 32-bit immediate!");
+    int64_t Imm = MI.getOperand(FIOperandNum + 3).getImm();
+    int Offset = FIOffset + (int)Imm;
+    if (!Is64Bit && !isInt<32>((int64_t)FIOffset + Imm))
+      MI.emitGenericError(("Requesting 64-bit offset in 32-bit immediate: " + MF.getName()).str());
     if (Offset != 0 || !tryOptimizeLEAtoMOV(II))
       MI.getOperand(FIOperandNum + 3).ChangeToImmediate(Offset);
   } else {

github-actions · 2025-01-22T03:55:04Z

✅ With the latest revision this PR passed the C/C++ code formatter.

llvm/lib/Target/X86/X86RegisterInfo.cpp

abhishek-kaushik22 · 2025-01-22T06:07:46Z

Maybe the IR from #121932 could be added as test

define dso_local i32 @main() #0 {
entry:
  %x = alloca [2147483647 x i8], align 16
  %arrayidx = getelementptr inbounds [2147483647 x i8], ptr %x, i64 0, i64 -42
  store i8 33, ptr %arrayidx, align 2
  ret i32 0
}

attributes #0 = { noinline nounwind optnone uwtable "frame-pointer"="all" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cmov,+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }

llvm/test/CodeGen/X86/large-displacements.ll

llvm/lib/Target/X86/X86RegisterInfo.cpp

RKSimon · 2025-01-31T13:46:28Z

Please can you add test coverage for #113856 as well - note its a fast-isel bug

wesleywiser · 2025-02-08T17:37:50Z

Thanks for finding those issues! I've added a test to cover #113856.

llvm/lib/Target/X86/X86RegisterInfo.cpp

llvm/test/CodeGen/X86/large-displacements-fastisel.ll

llvm/lib/Target/X86/X86RegisterInfo.cpp

wesleywiser · 2025-07-16T14:56:57Z

Hi @RKSimon, just a friendly ping for review when you get a chance. Thanks!

wesleywiser · 2025-07-24T00:17:37Z

Hi @RKSimon, just wanted to remind you that I think this is ready for another round of review when you have some time. Thank you!

RKSimon

LGTM with one minor @phoebewang @arsenm any further comments?

llvm/test/CodeGen/X86/large-displacements.ll

llvm/lib/Target/X86/X86RegisterInfo.h

phoebewang · 2025-07-24T10:56:32Z

If I read the code correctly, it not only emit error for 32-bit but also fix the bug in 64-bit. The title and description don't mention the latter?

e-kud · 2025-07-24T12:27:13Z

llvm/lib/Target/X86/X86RegisterInfo.cpp

+      RS->enterBasicBlockEnd(MBB);
+      RS->backward(std::next(II));
+
+      Register ScratchReg = RS->scavengeRegisterBackwards(
+          X86::GR64RegClass, II, /*RestoreAfter=*/false, /*SPAdj=*/0,
+          /*AllowSpill=*/true);
+      assert(ScratchReg != 0 && "scratch reg was 0");
+      RS->setRegUsed(ScratchReg);
+
+      BuildMI(MBB, II, DL, TII->get(X86::MOV64ri), ScratchReg).addImm(Offset);
+
+      MI.getOperand(FIOperandNum + 3).setImm(0);
+      MI.getOperand(FIOperandNum + 2).setReg(ScratchReg);
+
+      return false;


Do we really need all this manual work with RegisterScavenging? There is already an existing mechanism that is used for AArch64. All we need here is to create a virtual register and define

bool X86RegisterInfo::requiresRegisterScavenging( const MachineFunction &MF) const { return !isInt<32>(MF.getFrameInfo().estimateStackSize(MF)); } bool X86RegisterInfo::requiresFrameIndexScavenging( const MachineFunction &MF) const { return true; }

I'm not very familiar with RegisterScavenging, is the compilation time a concern here? Also, setting the requiresFrameIndexScavenging to true allows to avoid unnecessary preemptive stack allocation in X86FrameLowering

Thanks for the feedback! I'm not super familiar with this code and I was pointed to using RegisterScavenging as a way to solve the issue of needing a scratch register here.

Looking at the mechanism in AArch64, I think X86 is not currently set up to use the same thing. Locally, in addition to requiresFrameIndexScavenging, I also needed to add an override to enable requiresVirtualBaseRegisters for LocalStackSlotAllocation to kick in. With that done, I also needed to override at least needsFrameBaseReg, isFrameOffsetLegal and materializeFrameBaseRegister which is quite a bit more code than the few lines needed here to use RegisterScavenging manually.

Have I misunderstood your suggestion or what is needed to implement it? Is this still the preferred approach in contrast to RegisterScavenging directly?

Hi @e-kud, just pinging you in case you missed the above message. Thanks!

This is...complicated and requires a lot of other context to consider using or not. It's well beyond the scope of this patch

arsenm

lgtm with error message phrasing tweak

llvm/lib/Target/X86/X86RegisterInfo.cpp

llvm/test/CodeGen/X86/avx512f-large-stack.ll

llvm/test/CodeGen/X86/large-displacements.ll

The assertion previously did not work correctly because the operand was being truncated to an `int` prior to comparison.

Enable RegisterScavenging for X86 so that we can scavenge a register to use if the frame is very, very large or if the displacement for an instruction is too large and we need to rewrite it to use the scavenged register.

wesleywiser · 2025-08-02T20:44:47Z

At this point, I believe all review feedback has been responded to and CI is green.

If there's no other feedback, I would appreciate someone merging for me as I do not have merge rights. Thanks!

llvm-ci · 2025-08-03T10:21:24Z

LLVM Buildbot has detected a new failure on builder llvm-clang-x86_64-expensive-checks-debian running on gribozavr4 while building llvm at step 6 "test-build-unified-tree-check-all".

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

Here is the relevant piece of the build log for the reference

Step 6 (test-build-unified-tree-check-all) failure: test (failure)
******************** TEST 'LLVM :: CodeGen/X86/large-displacements.ll' FAILED ********************
Exit Code: 1

Command Output (stderr):
--
not /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/llc < /b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/test/CodeGen/X86/large-displacements.ll -mtriple=i686 -filetype=null 2>&1 | /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/FileCheck /b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/test/CodeGen/X86/large-displacements.ll -check-prefix=ERR-i686 # RUN: at line 1
+ /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/FileCheck /b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/test/CodeGen/X86/large-displacements.ll -check-prefix=ERR-i686
+ not /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bin/llc -mtriple=i686 -filetype=null
/b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/test/CodeGen/X86/large-displacements.ll:46:13: error: ERR-i686: expected string not found in input
; ERR-i686: error: <unknown>:0:0: 64-bit offset calculated but target is 32-bit
            ^
<stdin>:1:68: note: scanning from here
error: <unknown>:0:0: 64-bit offset calculated but target is 32-bit
                                                                   ^
<stdin>:2:1: note: possible intended match here
warning: <unknown>:0:0: stack frame size (4294967324) exceeds limit (4294967295) in function 'main'
^

Input file: <stdin>
Check file: /b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/test/CodeGen/X86/large-displacements.ll

-dump-input=help explains the following input dump.

Input was:
<<<<<<
            1: error: <unknown>:0:0: 64-bit offset calculated but target is 32-bit 
check:46'0                                                                        X error: no match found
            2: warning: <unknown>:0:0: stack frame size (4294967324) exceeds limit (4294967295) in function 'main' 
check:46'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
check:46'1     ?                                                                                                    possible intended match
            3:  
check:46'0     ~
            4: # After Prologue/Epilogue Insertion & Frame Finalization 
check:46'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            5: # Machine code for function main: NoPHIs, TracksLiveness, NoVRegs, TiedOpsRewritten, TracksDebugUserValues 
check:46'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            6: Frame Objects: 
check:46'0     ~~~~~~~~~~~~~~~
            7:  fi#-1: size=4, align=4, fixed, at location [SP-4] 
check:46'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            .
            .
            .
>>>>>>

--

********************

llvm-ci · 2025-08-03T10:21:59Z

LLVM Buildbot has detected a new failure on builder llvm-clang-x86_64-expensive-checks-ubuntu running on as-builder-4 while building llvm at step 7 "test-check-all".

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

Here is the relevant piece of the build log for the reference

Step 7 (test-check-all) failure: Test just built components: check-all completed (failure)
******************** TEST 'LLVM :: CodeGen/X86/large-displacements.ll' FAILED ********************
Exit Code: 1

Command Output (stderr):
--
not /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/build/bin/llc < /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/test/CodeGen/X86/large-displacements.ll -mtriple=i686 -filetype=null 2>&1 | /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/build/bin/FileCheck /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/test/CodeGen/X86/large-displacements.ll -check-prefix=ERR-i686 # RUN: at line 1
+ not /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/build/bin/llc -mtriple=i686 -filetype=null
+ /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/build/bin/FileCheck /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/test/CodeGen/X86/large-displacements.ll -check-prefix=ERR-i686
/home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/test/CodeGen/X86/large-displacements.ll:46:13: error: ERR-i686: expected string not found in input
; ERR-i686: error: <unknown>:0:0: 64-bit offset calculated but target is 32-bit
            ^
<stdin>:1:68: note: scanning from here
error: <unknown>:0:0: 64-bit offset calculated but target is 32-bit
                                                                   ^
<stdin>:2:1: note: possible intended match here
warning: <unknown>:0:0: stack frame size (4294967324) exceeds limit (4294967295) in function 'main'
^

Input file: <stdin>
Check file: /home/buildbot/worker/as-builder-4/ramdisk/expensive-checks/llvm-project/llvm/test/CodeGen/X86/large-displacements.ll

-dump-input=help explains the following input dump.

Input was:
<<<<<<
            1: error: <unknown>:0:0: 64-bit offset calculated but target is 32-bit 
check:46'0                                                                        X error: no match found
            2: warning: <unknown>:0:0: stack frame size (4294967324) exceeds limit (4294967295) in function 'main' 
check:46'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
check:46'1     ?                                                                                                    possible intended match
            3:  
check:46'0     ~
            4: # After Prologue/Epilogue Insertion & Frame Finalization 
check:46'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            5: # Machine code for function main: NoPHIs, TracksLiveness, NoVRegs, TiedOpsRewritten, TracksDebugUserValues 
check:46'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            6: Frame Objects: 
check:46'0     ~~~~~~~~~~~~~~~
            7:  fi#-1: size=4, align=4, fixed, at location [SP-4] 
check:46'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            .
            .
            .
>>>>>>

--

********************

abhishek-kaushik22 · 2025-08-03T10:43:18Z

Looks like the large-displacements.ll tests needs an update, I'm trying to fix this.

wesleywiser · 2025-08-03T17:20:23Z

llvm/lib/Target/X86/X86RegisterInfo.cpp

+    // ... for 32-bit targets, this is a bug!
+    if (!Is64Bit && !FitsIn32Bits)
+      MI.emitGenericError(("64-bit offset calculated but target is 32-bit"));
+


I think the issue is that while we report an error here, we leave the operand in the instruction which the verifier then reports. What's the right approach to resolve that?

I guess we could replace the overside operand with a saturated value or 0 or something. Or perhaps replace the entire instruction with a trap, etc.

Trap would be nicer, see #124217

Thanks for the suggestion @phoebewang! I've implemented that in #152239.

llvm-ci · 2025-08-03T19:56:14Z

LLVM Buildbot has detected a new failure on builder llvm-clang-x86_64-sie-win running on sie-win-worker while building llvm at step 7 "test-build-unified-tree-check-all".

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

Here is the relevant piece of the build log for the reference

Step 7 (test-build-unified-tree-check-all) failure: test (failure)
******************** TEST 'lld :: COFF/import_weak_alias.test' FAILED ********************
Exit Code: 3221225477

Command Output (stdout):
--
# RUN: at line 3
split-file Z:\b\llvm-clang-x86_64-sie-win\llvm-project\lld\test\COFF\import_weak_alias.test Z:\b\llvm-clang-x86_64-sie-win\build\tools\lld\test\COFF\Output\import_weak_alias.test.tmp.dir
# executed command: split-file 'Z:\b\llvm-clang-x86_64-sie-win\llvm-project\lld\test\COFF\import_weak_alias.test' 'Z:\b\llvm-clang-x86_64-sie-win\build\tools\lld\test\COFF\Output\import_weak_alias.test.tmp.dir'
# note: command had no output on stdout or stderr
# RUN: at line 4
z:\b\llvm-clang-x86_64-sie-win\build\bin\llvm-mc.exe --filetype=obj -triple=x86_64-windows-msvc Z:\b\llvm-clang-x86_64-sie-win\build\tools\lld\test\COFF\Output\import_weak_alias.test.tmp.dir/foo.s -o Z:\b\llvm-clang-x86_64-sie-win\build\tools\lld\test\COFF\Output\import_weak_alias.test.tmp.foo.obj
# executed command: 'z:\b\llvm-clang-x86_64-sie-win\build\bin\llvm-mc.exe' --filetype=obj -triple=x86_64-windows-msvc 'Z:\b\llvm-clang-x86_64-sie-win\build\tools\lld\test\COFF\Output\import_weak_alias.test.tmp.dir/foo.s' -o 'Z:\b\llvm-clang-x86_64-sie-win\build\tools\lld\test\COFF\Output\import_weak_alias.test.tmp.foo.obj'
# note: command had no output on stdout or stderr
# RUN: at line 5
z:\b\llvm-clang-x86_64-sie-win\build\bin\llvm-mc.exe --filetype=obj -triple=x86_64-windows-msvc Z:\b\llvm-clang-x86_64-sie-win\build\tools\lld\test\COFF\Output\import_weak_alias.test.tmp.dir/qux.s -o Z:\b\llvm-clang-x86_64-sie-win\build\tools\lld\test\COFF\Output\import_weak_alias.test.tmp.qux.obj
# executed command: 'z:\b\llvm-clang-x86_64-sie-win\build\bin\llvm-mc.exe' --filetype=obj -triple=x86_64-windows-msvc 'Z:\b\llvm-clang-x86_64-sie-win\build\tools\lld\test\COFF\Output\import_weak_alias.test.tmp.dir/qux.s' -o 'Z:\b\llvm-clang-x86_64-sie-win\build\tools\lld\test\COFF\Output\import_weak_alias.test.tmp.qux.obj'
# note: command had no output on stdout or stderr
# RUN: at line 6
z:\b\llvm-clang-x86_64-sie-win\build\bin\lld-link.exe Z:\b\llvm-clang-x86_64-sie-win\build\tools\lld\test\COFF\Output\import_weak_alias.test.tmp.qux.obj Z:\b\llvm-clang-x86_64-sie-win\build\tools\lld\test\COFF\Output\import_weak_alias.test.tmp.foo.obj -out:Z:\b\llvm-clang-x86_64-sie-win\build\tools\lld\test\COFF\Output\import_weak_alias.test.tmp.dll -dll
# executed command: 'z:\b\llvm-clang-x86_64-sie-win\build\bin\lld-link.exe' 'Z:\b\llvm-clang-x86_64-sie-win\build\tools\lld\test\COFF\Output\import_weak_alias.test.tmp.qux.obj' 'Z:\b\llvm-clang-x86_64-sie-win\build\tools\lld\test\COFF\Output\import_weak_alias.test.tmp.foo.obj' '-out:Z:\b\llvm-clang-x86_64-sie-win\build\tools\lld\test\COFF\Output\import_weak_alias.test.tmp.dll' -dll
# .---command stderr------------
# | PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
# | Stack dump:
# | 0.	Program arguments: z:\\b\\llvm-clang-x86_64-sie-win\\build\\bin\\lld-link.exe Z:\\b\\llvm-clang-x86_64-sie-win\\build\\tools\\lld\\test\\COFF\\Output\\import_weak_alias.test.tmp.qux.obj Z:\\b\\llvm-clang-x86_64-sie-win\\build\\tools\\lld\\test\\COFF\\Output\\import_weak_alias.test.tmp.foo.obj -out:Z:\\b\\llvm-clang-x86_64-sie-win\\build\\tools\\lld\\test\\COFF\\Output\\import_weak_alias.test.tmp.dll -dll
# | Exception Code: 0xC0000005
# | #0 0x00007ff8b39c1b39 (C:\Windows\System32\KERNELBASE.dll+0x41b39)
# | #1 0x00007ff7d4f6bb18 (z:\b\llvm-clang-x86_64-sie-win\build\bin\lld-link.exe+0xcbb18)
# | #2 0x00007ff7d4ff32db (z:\b\llvm-clang-x86_64-sie-win\build\bin\lld-link.exe+0x1532db)
# | #3 0x00007ff7d4f4d9aa (z:\b\llvm-clang-x86_64-sie-win\build\bin\lld-link.exe+0xad9aa)
# | #4 0x00007ff7d4f4da14 (z:\b\llvm-clang-x86_64-sie-win\build\bin\lld-link.exe+0xada14)
# | #5 0x00007ff7d76bfc54 (z:\b\llvm-clang-x86_64-sie-win\build\bin\lld-link.exe+0x281fc54)
# | #6 0x00007ff8b6ad7ac4 (C:\Windows\System32\KERNEL32.DLL+0x17ac4)
# | #7 0x00007ff8b6ffa8c1 (C:\Windows\SYSTEM32\ntdll.dll+0x5a8c1)
# `-----------------------------
# error: command failed with exit status: 0xc0000005

--

********************

Xazax-hun · 2025-08-04T10:31:29Z

Based on the discussion in #151860 looks like this needs to be reverted for now. Is someone looking into that?

…ing for huge frame offsets" (#151975) Reverts #123872 - this is breaking on EXPENSIVE_CHECKS builds Co-authored-by: Abhishek Kaushik <abhishek.kaushik@intel.com>

RKSimon · 2025-08-04T14:33:45Z

@Xazax-hun @wesleywiser @abhishek-kaushik22 this has now been reverted

…4-bit lowering for huge frame offsets" (#151975) Reverts llvm/llvm-project#123872 - this is breaking on EXPENSIVE_CHECKS builds Co-authored-by: Abhishek Kaushik <abhishek.kaushik@intel.com>

@arsenm

…huge frame offsets (llvm#123872) The assertion previously did not work correctly because the operand was being truncated to an `int` prior to comparison. Change the assertion into a a reported error as suggested in llvm#101840 (comment) by @arsenm Finally, fix the lowering on 64-bit targets so that offsets larger than 32-bit are correctly addressed and add tests for various reported issues.

@arsenm

…huge frame offsets (llvm#123872) The assertion previously did not work correctly because the operand was being truncated to an `int` prior to comparison. Change the assertion into a a reported error as suggested in llvm#101840 (comment) by @arsenm Finally, fix the lowering on 64-bit targets so that offsets larger than 32-bit are correctly addressed and add tests for various reported issues.

@arsenm

…huge frame offsets (llvm#123872) The assertion previously did not work correctly because the operand was being truncated to an `int` prior to comparison. Change the assertion into a a reported error as suggested in llvm#101840 (comment) by @arsenm Finally, fix the lowering on 64-bit targets so that offsets larger than 32-bit are correctly addressed and add tests for various reported issues.

@arsenm

…huge frame offsets (llvm#123872) The assertion previously did not work correctly because the operand was being truncated to an `int` prior to comparison. Change the assertion into a a reported error as suggested in llvm#101840 (comment) by @arsenm Finally, fix the lowering on 64-bit targets so that offsets larger than 32-bit are correctly addressed and add tests for various reported issues.

…ing for huge frame offsets" (llvm#151975) Reverts llvm#123872 - this is breaking on EXPENSIVE_CHECKS builds Co-authored-by: Abhishek Kaushik <abhishek.kaushik@intel.com>

llvmbot added the backend:X86 label Jan 22, 2025

wesleywiser force-pushed the fix_32_bit_immediate_assert branch from c82b6db to 0dd16eb Compare January 22, 2025 03:56

arsenm reviewed Jan 22, 2025

View reviewed changes

llvm/lib/Target/X86/X86RegisterInfo.cpp Outdated Show resolved Hide resolved

abhishek-kaushik22 linked an issue Jan 22, 2025 that may be closed by this pull request

[clang] Assertion `(!Is64Bit || isInt<32>((long long)FIOffset + Imm)) && "Requesting 64-bit offset in 32-bit immediate!"' failed #121932

Closed

wesleywiser force-pushed the fix_32_bit_immediate_assert branch from 0dd16eb to ecc78a2 Compare January 23, 2025 04:57

arsenm reviewed Jan 23, 2025

View reviewed changes

wesleywiser force-pushed the fix_32_bit_immediate_assert branch from ecc78a2 to 79d4afd Compare February 8, 2025 17:32

wesleywiser force-pushed the fix_32_bit_immediate_assert branch from 79d4afd to 58e318d Compare February 11, 2025 00:07

RKSimon reviewed Feb 11, 2025

View reviewed changes

wesleywiser force-pushed the fix_32_bit_immediate_assert branch from 58e318d to fd0853c Compare July 7, 2025 23:29

llvmbot added the llvm:codegen label Jul 7, 2025

wesleywiser force-pushed the fix_32_bit_immediate_assert branch from fd0853c to 54a7703 Compare July 8, 2025 00:50

wesleywiser requested a review from RKSimon July 8, 2025 21:18

RKSimon approved these changes Jul 24, 2025

View reviewed changes

llvm/test/CodeGen/X86/large-displacements.ll Show resolved Hide resolved

phoebewang reviewed Jul 24, 2025

View reviewed changes

llvm/lib/Target/X86/X86RegisterInfo.h Show resolved Hide resolved

phoebewang requested a review from e-kud July 24, 2025 10:52

e-kud reviewed Jul 24, 2025

View reviewed changes

wesleywiser changed the title ~~[X86] Fix 32-bit immediate assertion and convert into backend error~~ [X86] Correct 32-bit immediate assertion and fix 64-bit lowering for huge frame offsets Jul 28, 2025

arsenm reviewed Aug 1, 2025

View reviewed changes

llvm/lib/Target/X86/X86RegisterInfo.cpp Outdated Show resolved Hide resolved

llvm/test/CodeGen/X86/avx512f-large-stack.ll Outdated Show resolved Hide resolved

llvm/test/CodeGen/X86/large-displacements.ll Outdated Show resolved Hide resolved

nikic mentioned this pull request Aug 2, 2025

Regressions with large (2-4GB) stack arrays on large stacks rust-lang/rust#83060

Open

wesleywiser added 2 commits August 2, 2025 19:48

[X86] Fix 32-bit immediate assertion and convert into backend error

f5326bc

The assertion previously did not work correctly because the operand was being truncated to an `int` prior to comparison.

[X86] Fix overflows for very large frames

00bea8d

Enable RegisterScavenging for X86 so that we can scavenge a register to use if the frame is very, very large or if the displacement for an instruction is too large and we need to rewrite it to use the scavenged register.

wesleywiser force-pushed the fix_32_bit_immediate_assert branch from 54a7703 to 00bea8d Compare August 2, 2025 20:06

abhishek-kaushik22 merged commit 69bec0a into llvm:main Aug 3, 2025
9 checks passed

RKSimon mentioned this pull request Aug 3, 2025

[X86] Update large-displacement.ll #151860

Closed

wesleywiser commented Aug 3, 2025

View reviewed changes

RKSimon mentioned this pull request Aug 4, 2025

Revert "[X86] Correct 32-bit immediate assertion and fix 64-bit lowering for huge frame offsets" #151975

Merged

[X86] Correct 32-bit immediate assertion and fix 64-bit lowering for huge frame offsets #123872

[X86] Correct 32-bit immediate assertion and fix 64-bit lowering for huge frame offsets #123872

Uh oh!

Conversation

wesleywiser commented Jan 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

llvmbot commented Jan 22, 2025

Uh oh!

github-actions bot commented Jan 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

abhishek-kaushik22 commented Jan 22, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

RKSimon commented Jan 31, 2025

Uh oh!

wesleywiser commented Feb 8, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

wesleywiser commented Jul 16, 2025

Uh oh!

wesleywiser commented Jul 24, 2025

Uh oh!

RKSimon left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

phoebewang commented Jul 24, 2025

Uh oh!

e-kud Jul 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wesleywiser Jul 28, 2025

Choose a reason for hiding this comment

Uh oh!

wesleywiser Jul 31, 2025

Choose a reason for hiding this comment

Uh oh!

arsenm Aug 1, 2025

Choose a reason for hiding this comment

Uh oh!

arsenm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

wesleywiser commented Aug 2, 2025

Uh oh!

Uh oh!

llvm-ci commented Aug 3, 2025

Uh oh!

llvm-ci commented Aug 3, 2025

Uh oh!

abhishek-kaushik22 commented Aug 3, 2025

Uh oh!

wesleywiser Aug 3, 2025

Choose a reason for hiding this comment

Uh oh!

phoebewang Aug 6, 2025

Choose a reason for hiding this comment

Uh oh!

wesleywiser Aug 6, 2025

Choose a reason for hiding this comment

Uh oh!

llvm-ci commented Aug 3, 2025

Uh oh!

Xazax-hun commented Aug 4, 2025

wesleywiser commented Jan 22, 2025 •

edited

Loading

github-actions bot commented Jan 22, 2025 •

edited

Loading

e-kud Jul 24, 2025 •

edited

Loading