Re: [PATCH, RFC, rs6000] PR80791 Consider doloop in ivopts

[Richard Biener <rguenther@suse.de>]

On April 26, 2019 6:59:43 PM GMT+02:00, Segher Boessenkool <segher@kernel.crashing.org> wrote:
>On Fri, Apr 26, 2019 at 10:26:52PM +0800, Kewen.Lin wrote:
>> on 2019/4/26 下午3:16, Richard Biener wrote:
>> > We should think about possible ways of encoding doloop at IVOPTs
>> > time rather than trying to re-analyze at RTL.  I suppose we can
>> > easily set a flag in struct loop but I'm not familiar enough with
>> > the doloop pass to tell whether that is good enough.  Also we
>> > can maybe move doloop to GIMPLE completely?  I remember some
>> > targets have loop size constraints here as well, so I guess
>> > that isn't easily possible.
>
>> It's a very good point, but I'm afraid that it's impossible to move
>the 
>> whole doloop analysis pass to GIMPLE.  When I implemented this hook 
>> rs6000_predict_doloop_p, I went through all the checks in
>doloop_optimize.
>> I found it looks impossible to imitate all of them at GIMPLE,
>especially 
>> for gen_doloop_end check, jump insn check and register liveness
>clobber
>> check.  Even if we can make hook to check expanded RTL insn sequence
>in 
>> GIMPLE, but it happens too early, some information may not be exact
>enough,
>> many following passes could update what the analysis is based on.
>
>But you could set a flag in gimple, and have the RTL pass only do the
>final mechanics of making things a counted loop -- including generating
>the code for when it cannot do the doloop, which indeed will happen for
>many different reasons, many target-specific, but it is probably pretty
>easy to predict when we *can* use one, and we can do that
>optimistically,
>it's not so very much worse code to have to do it with a few
>instructions
>instead of e.g. a bdnz; there are many optimisation passes after this
>that can still improve the code (cprop, cse, combine).
>
>So, make it a doloop in gimple, and still have the rtl pass, but that
>only reverts it to a non-doloop if it turns out it has to.  Does that
>sound like a good plan?

Yes, that's more or less what I had in mind. Note that you'd have a doloop early in RTL, sth we might not expect? 

Maybe we already have a GIMPLE way of saying decrement and test zero (one of the overflow builtins?), if not we'd need to add such to have 

  Flag_1 = IFN_decandtest (i_2);
If (Flag_1! = 0)
 ... 

As 'doloop-end' on GIMPLE. Just adjusting RTL expansion to catch a regular Dec and test would be possible
As well of course. 

Richard. 

>
>Segher