diff options
| author | Jakub Jelinek <jakub@redhat.com> | 2023-03-28 10:43:08 +0200 |
|---|---|---|
| committer | Jakub Jelinek <jakub@redhat.com> | 2023-03-28 10:43:08 +0200 |
| commit | 4b5ef857f5faf09f274c0a95c67faaa80d198124 (patch) | |
| tree | 548066d9669ab3225dbbf31fb3536ea825958e70 /gcc/range-op-float.cc | |
| parent | a21bd7faba67997a6da457dbda16f15bca1a9156 (diff) | |
| download | gcc-4b5ef857f5faf09f274c0a95c67faaa80d198124.zip gcc-4b5ef857f5faf09f274c0a95c67faaa80d198124.tar.gz gcc-4b5ef857f5faf09f274c0a95c67faaa80d198124.tar.bz2 | |
i386: Require just 32-bit alignment for SLOT_FLOATxFDI_387 -m32 -mpreferred-stack-boundary=2 DImode temporaries [PR109276]
The following testcase ICEs since r11-2259 because assign_386_stack_local
-> assign_stack_local -> ix86_local_alignment now uses 64-bit alignment
for DImode temporaries rather than 32-bit as before.
Most of the spots in the backend which ask for DImode temporaries are during
expansion and those apparently are handled fine with -m32
-mpreferred-stack-boundary=2, we dynamically realign the stack in that case
(most of the spots actually don't need that alignment but at least one
does), then 2 spots are in STV which I assume also work correctly.
But during splitting we can create a DImode slot which doesn't need to be
64-bit alignment (it is nicer for performance though), when we apparently
aren't able to detect it for dynamic stack realignment purposes.
The following patch just makes the slot 32-bit aligned in that rare case.
2023-03-28 Jakub Jelinek <jakub@redhat.com>
PR target/109276
* config/i386/i386.cc (assign_386_stack_local): For DImode
with SLOT_FLOATxFDI_387 and -m32 -mpreferred-stack-boundary=2 pass
align 32 rather than 0 to assign_stack_local.
* gcc.target/i386/pr109276.c: New test.
Diffstat (limited to 'gcc/range-op-float.cc')
0 files changed, 0 insertions, 0 deletions