On 5/14/19 1:35 PM, 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. I won't claim to know what the solution is here -- IVOPTS is certainly a pain point and not just with low overhead looping constructs.
Of course we had similar problems when we did this on RTL even with access to the low level costing information -- often the right choice would depends on some factor external to the current loop. In a perfect world we'd probably keep the current stuff as-is, then lower a bit to expose addressing modes and some other target dependencies in a lowered gimple. But we're certainly not there. jeff
