On April 26, 2019 6:59:43 PM GMT+02:00, Segher Boessenkool <seg...@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
