> -----Original Message----- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of > Jiangning Liu > Sent: Tuesday, December 27, 2011 5:10 PM > To: 'Richard Guenther' > Cc: Michael Matz; gcc@gcc.gnu.org > Subject: RE: A case exposing code sink issue > > > > > The job to do this is final value replacement, not sinking (we do not > > sink non-invariant expressions - you'd have to translate them through > > the loop-closed SSA exit PHI node, certainly doable, patches > > welcome ;)). > > > > Richard, > > In final value replacement, expression "&a + D.xxxx" can be figured out, > while "&a[i_xxx]" failed to be CHRECed, so I'm wondering if we should > lower > &a[i_xxx] to "&a + unitsize(a) * i_xxx" first? It seems GCC intends to > keep > &a[i_xxx] until cfgexpand pass. Or we have to directly modify CHREC > algorithm to get it calculated? > > Appreciate your kindly help in advance! >
Richard, Now I have a patch working for the case of step "i++", by directly modifying scalar evolution algorithm. the following code would be generated after SCCP, l # i_13 = PHI <i_6(7), k_2(D)(4)> a_p.0_4 = &a[i_13]; MEM[(int *)&a][i_13] = 100; i_6 = i_13 + 1; if (i_6 <= 999) goto <bb 7>; else goto <bb 6>; <bb 6>: a_p_lsm.5_11 = &MEM[(void *)&a + 3996B]; a_p = a_p_lsm.5_11; goto <bb 3>; It looks good, but I still have problem when the case has step "i+=k". For this case the value of variable i exiting loop isn't invariant, the algorithm below in scalar evolution doesn't work on it, compute_overall_effect_of_inner_loop() { ... tree nb_iter = number_of_latch_executions (inner_loop); if (nb_iter == chrec_dont_know) return chrec_dont_know; else { tree res; /* evolution_fn is the evolution function in LOOP. Get its value in the nb_iter-th iteration. */ res = chrec_apply (inner_loop->num, evolution_fn, nb_iter); if (chrec_contains_symbols_defined_in_loop (res, loop->num)) res = instantiate_parameters (loop, res); /* Continue the computation until ending on a parent of LOOP. */ return compute_overall_effect_of_inner_loop (loop, res); } } In theory, we can still have the transformation like below even if the step is "i+=k", # i_13 = PHI <i_6(7), k_2(D)(4)> i_14 = i_13, a_p.0_4 = &a[i_13]; MEM[(int *)&a][i_13] = 100; i_6 = i_13 + k_2(D); // i+=k if (i_6 <= 999) goto <bb 7>; else goto <bb 6>; <bb 6>: a_p_lsm.5_11 = &a[i_14]; a_p = a_p_lsm.5_11; goto <bb 3>; But I realize this is not a loop closed SSA form at all, because i_14 is being used out of the loop. Where could we extend the liverange of variable i in GCC infrastructure and finally solve this problem? > Thanks, > -Jiangning > > >