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".
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;
