On Tue, Feb 2, 2016 at 5:54 PM, Kyrill Tkachov <kyrylo.tkac...@foss.arm.com> wrote: > Hi Richard, > > > On 02/02/16 14:56, Richard Sandiford wrote: >> >> In PR 69577 we have: >> >> A: (set (reg:V2TI X) ...) >> B: (set (subreg:TI (reg:V2TI X) 0) ...) >> >> X gets allocated to an AVX register, as usual for V2TI. The problem is >> that the movti for B doesn't then preserve the other half of X, even >> though the subreg semantics are supposed to guarantee that. >> >> If instead the same value had been set by: >> >> A': (set (subreg:TI (reg:V2TI X) 16) ...) >> B: (set (subreg:TI (reg:V2TI X) 0) ...) >> >> the subreg in A' would have prevented the use of AVX registers for X, >> since you can't directly access the high part. >> >> IMO these are really the same thing. An alternative way to view it >> is that the original sequence is equivalent to: >> >> A: (set (reg:V2TI X) ...) >> B1: (set (subreg:TI (reg:V2TI X) 0) ...) >> B2: (set (subreg:TI (reg:V2TI X) 16) (subreg:TI (reg:V2TI X) 16)) >> >> in which B2 is a no-op and therefore implicit. The handling ought >> to be the same regardless of whether there is an rtl insn that >> explicitly assigns to (subreg:TI (reg:V2TI X) 16). >> >> This patch implements that idea. Hopefully the comments explain >> what's going on. >> >> Tested on x86_64-linux-gnu so far. Will test on aarch64-linux-gnu and >> arm-linux-gnueabihf as well. OK to install if the additional testing >> succeeds? > > > For me this patch causes an ICE when building libgcc during an > aarch64-none-elf build. > It's a segfault with the trace: > 0xb0ac2a crash_signal > $SRC/gcc/toplev.c:335 > 0xa7cfd7 init_subregs_of_mode() > $SRC/gcc/reginfo.c:1345 > 0x96fc4b init_costs > $SRC/gcc/ira-costs.c:2187 > 0x97419e ira_set_pseudo_classes(bool, _IO_FILE*) > $SRC/gcc/ira-costs.c:2237 > 0x106fd1e alloc_global_sched_pressure_data > $SRC/gcc/haifa-sched.c:7244 > 0x106fd1e sched_init() > $SRC/gcc/haifa-sched.c:7394 > 0x107109a haifa_sched_init() > $SRC/gcc/haifa-sched.c:7406 > 0xab37ac schedule_insns() > $SRC/gcc/sched-rgn.c:3504 > 0xab3f5b rest_of_handle_sched > $SRC/gcc/sched-rgn.c:3717 > 0xab3f5b execute > $SRC/gcc/sched-rgn.c:3825
Also on x86_64-linux-gnu when building -m32 multilib: Program received signal SIGSEGV, Segmentation fault. 0x0000000000d28264 in init_subregs_of_mode () at /home/uros/gcc-svn/trunk/gcc/reginfo.c:1345 1345 FOR_EACH_INSN_DEF (def, insn) (gdb) p insn $1 = (rtx_insn *) 0x7fffef9f4d40 (gdb) p debug_rtx (insn) (code_label 60 31 39 10 9 "" [3 uses]) $2 = void (gdb) p def $3 = (df_ref) 0x0 Uros.
