Hi Richard, On Thu, 6 Jun 2019 at 22:07, Richard Sandiford <richard.sandif...@arm.com> wrote: > > Kugan Vivekanandarajah <kugan.vivekanandara...@linaro.org> writes: > > Hi Richard, > > > > On Thu, 6 Jun 2019 at 19:35, Richard Sandiford > > <richard.sandif...@arm.com> wrote: > >> > >> Kugan Vivekanandarajah <kugan.vivekanandara...@linaro.org> writes: > >> > Hi Richard, > >> > > >> > Thanks for the review. Attached is the latest patch. > >> > > >> > For testcase like cond_arith_1.c, with the patch, gcc ICE in fwprop. I > >> > am limiting fwprop in cases like this. Is there a better fix for this? > >> > index cf2c9de..2c99285 100644 > >> > --- a/gcc/fwprop.c > >> > +++ b/gcc/fwprop.c > >> > @@ -1358,6 +1358,15 @@ forward_propagate_and_simplify (df_ref use, > >> > rtx_insn *def_insn, rtx def_set) > >> > else > >> > mode = GET_MODE (*loc); > >> > > >> > + /* TODO. We can't get the mode for > >> > + (set (reg:VNx16BI 109) > >> > + (unspec:VNx16BI [ > >> > + (reg:SI 131) > >> > + (reg:SI 106) > >> > + ] UNSPEC_WHILE_LO)) > >> > + Thus, bailout when it is UNSPEC and MODEs are not compatible. */ > >> > + if (GET_MODE_CLASS (mode) != GET_MODE_CLASS (GET_MODE (reg))) > >> > + return false; > >> > new_rtx = propagate_rtx (*loc, mode, reg, src, > >> > optimize_bb_for_speed_p (BLOCK_FOR_INSN (use_insn))); > >> > >> What specifically goes wrong? The unspec above isn't that unusual -- > >> many unspecs have different modes from their inputs. > > > > cond_arith_1.c:38:1: internal compiler error: in paradoxical_subreg_p, > > at rtl.h:3130 > > 0x135f1d3 paradoxical_subreg_p(machine_mode, machine_mode) > > ../../88838/gcc/rtl.h:3130 > > 0x135f1d3 propagate_rtx > > ../../88838/gcc/fwprop.c:683 > > 0x135f4a3 forward_propagate_and_simplify > > ../../88838/gcc/fwprop.c:1371 > > 0x135f4a3 forward_propagate_into > > ../../88838/gcc/fwprop.c:1430 > > 0x135fdcb fwprop > > ../../88838/gcc/fwprop.c:1519 > > 0x135fdcb execute > > ../../88838/gcc/fwprop.c:1550 > > Please submit a full bug report, > > with preprocessed source if appropriate. > > > > > > in forward_propagate_and_simplify > > > > use_set: > > (set (reg:VNx16BI 96 [ loop_mask_52 ]) > > (unspec:VNx16BI [ > > (reg:SI 92 [ _3 ]) > > (reg:SI 95 [ niters.36 ]) > > ] UNSPEC_WHILE_LO)) > > > > reg: > > (reg:SI 92 [ _3 ]) > > > > *loc: > > (unspec:VNx16BI [ > > (reg:SI 92 [ _3 ]) > > (reg:SI 95 [ niters.36 ]) > > ] UNSPEC_WHILE_LO) > > > > src: > > (subreg:SI (reg:DI 136 [ ivtmp_101 ]) 0) > > > > use_insn: > > (insn 87 86 88 4 (parallel [ > > (set (reg:VNx16BI 96 [ loop_mask_52 ]) > > (unspec:VNx16BI [ > > (reg:SI 92 [ _3 ]) > > (reg:SI 95 [ niters.36 ]) > > ] UNSPEC_WHILE_LO)) > > (clobber (reg:CC 66 cc)) > > ]) 4255 {while_ultsivnx16bi} > > (expr_list:REG_UNUSED (reg:CC 66 cc) > > (nil))) > > > > I think we calculate the mode to be VNx16BI which is wrong? > > because of which in propgate_rtx, !paradoxical_subreg_p (mode, > > GET_MODE (SUBREG_REG (new_rtx))))) ICE > > Looks like something I hit on the ACLE branch, but didn't have a > non-ACLE reproducer for (see 065881acf0de35ff7818c1fc92769e1c106e1028). > > Does the attached work? The current call is wrong because "mode" > is the mode of "x", not the mode of "new_rtx".
Yes, attached patch works for this testcase. Are you planning to commit it to trunk. I will wait for this. Thanks, Kugan > > Thanks, > Richard > > > 2019-06-06 Richard Sandiford <richard.sandif...@arm.com> > > gcc/ > * fwprop.c (propagate_rtx): Fix call to paradoxical_subreg_p. > > Index: gcc/fwprop.c > =================================================================== > --- gcc/fwprop.c 2019-03-08 18:14:25.333011645 +0000 > +++ gcc/fwprop.c 2019-06-06 13:04:34.423476690 +0100 > @@ -680,7 +680,7 @@ propagate_rtx (rtx x, machine_mode mode, > || CONSTANT_P (new_rtx) > || (GET_CODE (new_rtx) == SUBREG > && REG_P (SUBREG_REG (new_rtx)) > - && !paradoxical_subreg_p (mode, GET_MODE (SUBREG_REG (new_rtx))))) > + && !paradoxical_subreg_p (new_rtx))) > flags |= PR_CAN_APPEAR; > if (!varying_mem_p (new_rtx)) > flags |= PR_HANDLE_MEM;