on 2019/4/27 上午12:59, Segher Boessenkool 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). >
Yes, we can set a flag to indicate this loop was predicted as doloop, which implicitly says we have checked some doloop criteria that are able to be checked in middle end. It can be well defined later. One question in mind is whether there are some other passes suffering the pain that the pass doesn't know the loop can be transformed to doloop or not and can't perform some optimization. I guess it decides what's the value and priority to make this non-trivial change. Do you happen to know some existing PRs? > 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? > Sounds good! Thanks Segher! > > Segher >
