Re: Re: [PATCH] Fix PRs 66502 and 67167

[Jiong Wang <jiong dot wang at foss dot arm dot com>]

On 21/08/15 10:47, Jiong Wang wrote:
> Richard Biener writes:
>
> > I see the following ICE:
> >
> > t.c:13:1: internal compiler error: in decompose_normal_address, at
> > rtlanal.c:6090
> >   }
> >   ^
> > 0xc94a37 decompose_normal_address
> >          /space/rguenther/tramp3d/trunk/gcc/rtlanal.c:6090
> > 0xc94d25 decompose_address(address_info*, rtx_def**, machine_mode,
> > unsigned char, rtx_code)
> >          /space/rguenther/tramp3d/trunk/gcc/rtlanal.c:6167
> > 0xc94dc3 decompose_mem_address(address_info*, rtx_def*)
> >          /space/rguenther/tramp3d/trunk/gcc/rtlanal.c:6187
> > 0xb61149 process_address_1
> >          /space/rguenther/tramp3d/trunk/gcc/lra-constraints.c:2867
> > 0xb61c4e process_address
> >          /space/rguenther/tramp3d/trunk/gcc/lra-constraints.c:3124
> > 0xb62607 curr_insn_transform
> >          /space/rguenther/tramp3d/trunk/gcc/lra-constraints.c:3419
> > 0xb65250 lra_constraints(bool)
> >          /space/rguenther/tramp3d/trunk/gcc/lra-constraints.c:4421
> >
> > that looks like a latent issue to me in an area of GCC I am not
> > familiar with.  I suggest to open a bugreport and CC Vladimir.
> Thanks for the info. Done https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67305

Richard,

  Though the ICE itself is caused by one latent bug in ARM backend 
(PR67305), while my
further double check shows there is performance regression since this 
patch. The regression
should have been caused by other gcc latent bugs in tree-vrp pass. 
Bugzilla created to track

  Thanks.

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68234

Regards,
Jiong

> > The r226850 change caused us to eliminate an induction variable
> > early (I suspect IVOPTs would have done this later anyway, but
> > I did not verify that):
> >
> > Replaced redundant PHI node defining bl_2 with c_1
> > Replaced c_1 + 1 with bl_15 in all uses of c_16 = c_1 + 1;
> > Removing dead stmt c_16 = c_1 + 1;
> > Removing dead stmt bl_2 = PHI <0(2), bl_15(3)>
> >
> > Thanks,
> > Richard.
> >
> > >    Thanks.