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? Segher
