[PATCH v2 3/3] Consider doloop cmp use in ivopts

[Jeff Law]

On 5/15/19 2:47 AM, 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 <linkw@linux.ibm.com> wrote:
>>>>
>>>> From: Kewen Lin <linkw@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?)?
That's my understanding of how at least some of the low overhead looping
instructions work on some ISAs (ppc included).  There's a special loop
count register and the low overhead looping insns handle the decrement
and branch.

This is similar, but different than something like m68k dbcc where the
counter is a GPR.

For architectures like PPC, we probably don't want to use the loop count
for anything else as it's likely expensive to get data in/out of the the
loop count register.

For architectures where the counter is stored in a GPR, then we have
more flexibility in how we use it.

So at least part of the problem is cost modeling of this.  It's all
pretty low level, so not really a good match for the goals of gimple.
But we may ultimately have no choice here but to be pragmatic like we've
done with stuff like vector widths and allow some target properties to
bleed in.

The only saving grace is the existence of low overhead loops is static
-- the target either has them or it doesn't.  Similarly whether or not
the counter is a GPR or not is a static property of the target.

> 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). 
It feels independent to me.

 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.
Agreed.

jeff