diff options
author | Richard Sandiford <richard.sandiford@arm.com> | 2024-08-21 17:35:47 +0100 |
---|---|---|
committer | Richard Sandiford <richard.sandiford@arm.com> | 2024-08-21 17:35:47 +0100 |
commit | ec9d6d45191f639482344362d048294e74587ca3 (patch) | |
tree | 5a0a2801aa0205f2202e9b85ae24b4d9721feb8d /gcc/fortran/simplify.cc | |
parent | 4a5d6118c10dfa4f1ed28ab4875bb80f2b2dca9d (diff) | |
download | gcc-master.zip gcc-master.tar.gz gcc-master.tar.bz2 |
The testcase contains a VNx2QImode pseudo that is live across a call
and that cannot be allocated a call-preserved register. LRA quite
reasonably tried to save it before the call and restore it afterwards.
Unfortunately, the target told it to do that in SImode, even though
punning between SImode and VNx2QImode is disallowed by both
TARGET_CAN_CHANGE_MODE_CLASS and TARGET_MODES_TIEABLE_P.
The natural class to use for SImode is GENERAL_REGS, so this led
to an unsalvageable situation in which we had:
(set (subreg:VNx2QI (reg:SI A) 0) (reg:VNx2QI B))
where A needed GENERAL_REGS and B needed FP_REGS. We therefore ended
up in a reload loop.
The hooks above should ensure that this situation can never occur
for incoming subregs. It only happened here because the target
explicitly forced it.
The decision to use SImode for modes smaller than 4 bytes dates
back to the beginning of the port, before 16-bit floating-point
modes existed. I'm not sure whether promoting to SImode really
makes sense for any FPR, but that's a separate performance/QoI
discussion. For now, this patch just disallows using SImode
when it is wrong for correctness reasons, since that should be
safer to backport.
gcc/
PR testsuite/116238
* config/aarch64/aarch64.cc (aarch64_hard_regno_caller_save_mode):
Only return SImode if we can convert to and from it.
gcc/testsuite/
PR testsuite/116238
* gcc.target/aarch64/sve/pr116238.c: New test.
Diffstat (limited to 'gcc/fortran/simplify.cc')
0 files changed, 0 insertions, 0 deletions