https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88850
Bug ID: 88850
Summary: [9 Regression] Hard register coming out of expand
causing reload to fail.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
Target: arm-none-linux-gnueabihf
The following testcase
typedef __builtin_neon_qi int8x8_t __attribute__ ((__vector_size__ (8)));
void
foo (int8x8_t z, int8x8_t x, int8x8_t v)
{
__builtin_neon_vuzpv8qi (&v, z, x);
}
ICEs when compiled with
-marm -O2 -march=armv7-a -mfloat-abi=softfp -mfpu=neon -S
-specs=aprofile-validation.specs -Wno-implicit-function-declaration
during reload
pr51968.c:12:1: error: insn does not satisfy its constraints:
12 | }
| ^
(insn 14 13 9 2 (set (reg:V8QI 6 r6 [113])
(reg:V8QI 0 r0 [ z ]))
"/data/tamchr01/gnu-work/src/gcc/gcc/testsuite/gcc.target/arm/pr51968.c":10:1
936 {*neon_movv8qi}
(nil))
during RTL pass: reload
it seems that the address taking of &v is causing it to emit hard registers
(r2) from expand already.
out of expand_call we get
(insn 3 2 4 2 (set (reg/v:V8QI 111 [ xD.5505 ])
(reg:V8QI 2 r2 [ xD.5505 ])) "pr51968.c":10:1 -1
(nil))
but have yet to figure out why.. the pattern itself seems sane to me..
