on 2019/5/15 下午4:47, Richard Biener wrote: > 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?)?
Yes, it takes one special hardware register "counter register" on Power. For other uses based on doloop IV, if there are no more suitable IVs, we still need one general reg for update and use. In the current patch, although we bypass this doloop cmp use, it's still allowed to have other uses to choose this doloop IV candidate. The costing is as usual. Since the doloop cmp use is actually free, we don't want ivopts to consider it and affect optimal IV set. > > 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. > In the previous version of patch, it's to make this doloop cmp use as zero cost with any iv cands (like it's invisible), sounds better fit in general cost model? But it requires us to preserve the doloop IV incase it's not chosen. The current version is to bind the doloop IV at the first place, bypass the choosing process and fill it directly if no better found later. For Power, either zero cost or bypass can coexist with the cost model framework. Thanks, Kewen > Richard. >
