A case exposing code sink issue

[Jiangning Liu]

> -----Original Message-----
> From: Andrew Pinski [mailto:pinskia@gmail.com]
> Sent: Thursday, November 24, 2011 12:15 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org
> Subject: Re: A case exposing code sink issue
> 
> On Wed, Nov 23, 2011 at 8:05 PM, Jiangning Liu <jiangning.liu@arm.com>
> wrote:
> > If this is the root cause, which optimization pass in GCC take the
> role to
> > sink them out of loop? How should we get it fixed?
> 
> lim1 handles the case just fine for me.  lim1 is the first loop pass.
> 
> After lim1 I get:
> 
> <bb 4>:
>   # i.1_34 = PHI <i.6_18(9), k.0_9(7)>
>   D.2934_5 = pretmp.11_33;
>   D.2936_7 = i.1_34 + D.2934_5;
>   a_p.2_8 = &a[D.2936_7];
>   a_p_lsm.13_37 = a_p.2_8;
>   b_p.3_13 = &b[D.2936_7];
>   b_p_lsm.14_38 = b_p.3_13;
>   MEM[(int *)&a][D.2936_7] = 7;
>   MEM[(int *)&b][D.2936_7] = 7;
>   i.6_18 = k.0_9 + i.1_34;
>   i_lsm.12_39 = i.6_18;
>   if (i.6_18 <= 511)
>     goto <bb 9>;
>   else
>     goto <bb 8>;
> 
> <bb 9>:
>   goto <bb 4>;
> 

&a[D.2936_7] and &b[D.2936_7] are not loop invariants, so it seems lim1 shouldn't be able to sink them, right? Do I misunderstand this optimization?

Thanks,
-Jiangning

> 
> 
> 
> Thanks,
> Andrew Pinski