On Tue, 14 May 2019, Bill Schmidt wrote: > On 5/14/19 2:13 PM, Jeff Law wrote: > > On 5/13/19 9:09 PM, li...@linux.ibm.com wrote: > >> From: Kewen Lin <li...@linux.ibm.com> > >> > >> Previous version link for background: > >> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html > >> > >> This hook is to predict whether one loop in gimple will > >> be transformed to low-overhead loop later in RTL, and > >> designed to be called in ivopts. > >> > >> "Since the low-overhead loop optimize transformation is > >> based on RTL, some of those checks are hard to be imitated > >> on gimple, so it's not possible to predict the current > >> loop will be transformed exactly in middle-end. But if we > >> can have most loop predicted precisely, it would be helpful. > >> It highly depends on target hook fine tuning. It's > >> acceptable to have some loops which can be transformed to > >> low-overhead loop but we don't catch. But we should try > >> our best to avoid to predict some loop as low-overhead loop > >> but which isn't." > >> > >> Bootstrapped and regression testing passed on powerpc64le. > >> > >> Is it ok for trunk? > >> > >> gcc/ChangeLog > >> > >> 2019-05-13 Kewen Lin <li...@gcc.gnu.org> > >> > >> PR middle-end/80791 > >> * target.def (predict_doloop_p): New hook. > >> * targhooks.h (default_predict_doloop_p): New declaration. > >> * targhooks.c (default_predict_doloop_p): New function. > >> * doc/tm.texi.in (TARGET_PREDICT_DOLOOP_P): New hook. > >> * doc/tm.texi: Regenerate. > >> * config/rs6000/rs6000.c (invalid_insn_for_doloop_p): New function. > >> (costly_iter_for_doloop_p): Likewise. > >> (rs6000_predict_doloop_p): Likewise. > >> (TARGET_PREDICT_DOLOOP_P): New macro. > > Trying to guess what the target is going to do, then changing the > > structure of the loops in gimple based on that guess -- is that really a > > good idea. It's fairly counter to many of the design goals around gimple. > > Understood -- but incorrect selection of ivars has a heavily detrimental > effect. > We have run into this problem many times on Power, where the cost model > wrongly > takes into effect the cost of the compare that will be absorbed into the bdnz > instruction. Hot loops can end up 15-20% worse. I don't see any reasonable > alternative to a target hook with the present IVOPTS cost model.
Note I would go with GIMPLE level detection of doloop style decrement and branch and just have a special path in its costing, for example not costing the compare at all in case there are doloop patterns? Richard.
