on 2019/4/26 下午3:16, Richard Biener wrote: > On Fri, 26 Apr 2019, Kewen.Lin wrote: > >> I was thinking whether this zero cost change just exposed >> an existing problem, then this kind of check should be for all >> cases not only for zero cost use, similar to >> expression_expensive_p? But why doesn't it happen before? >> Need more investigation. > > 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. > > Richard. Thanks Richard!
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.
