On Wed, 15 May 2019, Kewen.Lin wrote: > on 2019/5/14 下午3:26, Richard Biener wrote: > > On Tue, May 14, 2019 at 5:10 AM <li...@linux.ibm.com> wrote: > >> > >> From: Kewen Lin <li...@linux.ibm.com> > >> > >> Previous version link for background: > >> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html > >> > >> Firstly, it's to call predict_doloop_p hook to check this > >> loop will be transformed to doloop or not, if yes, find > >> the expected comp iv use and its dependent original iv, > >> set the iv candidate as bind_cand of the group. > >> In following candidate selection process, we will bypass > >> the group with bind_cand, since we don't want to affect > >> global decision making for an iv use which will be > >> eliminated eventually. At the time of iv candidate set > >> finalization, we will fill the cost pair for the group > >> with bind_cand. If the bind_cand is already in the final > >> set, then just use it. Otherwise, we can check whether one > >> of existing final set is better and fill with that if so. > >> > >> Bootstrapped and regression testing passed on powerpc64le. > >> > >> Is it ok for trunk? > > > > I wonder what prevents IVOPTs to consider a counter IV > > (eventually such candidate needs to be added if that's not > > already done) to be the most profitable variant w/o any > > of the other changes? I guess that would be costing of > > the IV adjust plus branch which we would need to lower > > in case there's nothing inside the loop that would make > > later doloop transform fail? > > > > Richard. > > > > If the question is for "w/o this patch", I think IVOPTs > can find counter IV as the most profitable one for the cmp > use in most time. But the key issue is that it may stop > us to bring in more iv cands. We have to add on iv cost > of new cand desirable for some iv use, it's probably more > than the cost of just using counter IV for the interest > use. > > If the question is for "w/i this patch", since we bypass > the doloop cmp use in candidate determination algorithm, > it's possible that some other iv cands are preferred for > the remaining uses rather than the counter IV. For example, > for some address type iv use, iv cand with memory based is > mostly better.
Ah, so the key issue is that the doloop IV is "free"? That is, it doesn't consume a general register and whatnot? That is allocating this IV doesn't really interfere with other IVs? But can other uses be based on the doloop IV easily (if the IV doesn't reside in a general reg?)? Otherwise I understand that IVOPTs doesn't properly cost the doloop IV update and conditional branch. That's clearly something we should fix (maybe even indepenently on other changes). One important thing is that we need to base costs on a common base to not compare apples and oranges, didn't dig into your patch in detail enough to see whether it fits into the general cost model or whether it is a hack ontop of everything. Richard.
