on 2019/6/17 下午9:44, Richard Biener wrote: > On Mon, 17 Jun 2019, Kewen.Lin wrote: > >> on 2019/6/17 下午8:08, Richard Biener wrote: >>> On June 17, 2019 11:59:30 AM GMT+02:00, Segher Boessenkool >>> <seg...@kernel.crashing.org> wrote: >>>> On Mon, Jun 17, 2019 at 10:51:49AM +0200, Richard Biener wrote: >>>>> On Mon, 17 Jun 2019, Kewen.Lin wrote: >>>>> >>>>>> Hi Segher and Bill, >>>>>> >>>>>> Thanks a lot for your review comments! I've updated the patch >>>> accordingly. >>>>>> >>>>>> The updated one attached. >>>>> >>>>> OK. I suppose all low-overhead loop instructions use a decrement to >>>> zero >>>>> style iterator? >>>> >>>> The documentation says decrement to 0, decrement to -1, and decrement >>>> to >>>> any negative are all supported. But all are decrement, yes. >>> >>> Hmm, so I wonder if we should tell IVOPTS the kind because the IV generated >>> has to match RTL doloops expectations? Thus return an enum value from the >>> hook? >>> >> >> I guess we don't need to make it in IVOPTs, since doloop_optimize can >> transform the loop closing to >> its expected pattern once it gets the iteration count, with target hook >> doloop_end. >> It's to modify the original closing into: >> niter -> 0 >> niter-1 -> -1 >> niter-n -> -n > > True, but this IV may affect other IVs choice (well, at least if it is > "cheap" to use the doloop IV in derived IVs which it is not for power). >
Good point! For those targets like power having counter register, it would be fine. For the other, I'm sorry that I'm not sure how the sequence looks like. All decrement/cmp kept? Just like normal but it has hardware fusion support? Maybe we can add one more iv cand specific for this kind of use, assign negative cost for this specific pair (group/cand), it can give chances to be selected for other uses if it's better? Thanks, Kewen > Richard. >
