> -----Original Message----- > From: Andrew Pinski [mailto:pins...@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....@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