> The question: > > The insn which causes the segfault is: > (debug_insn 1548 1547 1886 11 (var_location:V4HI __b (subreg:V4HI > (reg:V8HI 125 d31 [orig:657 vr ] [657]) 0)) upsampling_neon.c:850 -1 > (nil)) > > The variable vr is declared as a NEON vector of 8 16bit integers, and > -frename-registers has caused it to be separated into 2 64bit parts. > So the register allocation is ok, but if considered in isolation the > part which reads (reg:V8HI 125 d31 [orig:657 vr ] [657]) represents a > non-existent register, as the last physical register is d31 (regnos > 125,126). > > When this is processed by sched_analyze_2 in sched-deps.c, the subreg > is handled by treating it as the included (reg), and it therefore adds > dependencies on invalid physical registers, which leads to a segfault. > If the variable was not assigned to d31 (as in fsf 4.7), then it would > not crash, but would add false dependencies. > > So, my question is: Is the above RTL valid? In other words, should > sched-deps.c handle this, or should all reg RTL expressions represent > fully valid registers?
If d31 cannot contain a V8HImode value, then (reg:V8HI 125 d31) should not be generated under normal circumstances. Here it's a var location so this might be less clear, but still. How are the REG and SUBREG generated exactly? -- Eric Botcazou
