Hi Segher, on 2019/7/23 上午5:43, Segher Boessenkool wrote: > On Mon, Jul 22, 2019 at 09:18:10AM +0200, Richard Biener wrote: >> On Mon, 22 Jul 2019, Segher Boessenkool wrote: >> >>> Hi! >>> >>> (Maybe I am missing half of the discussion -- sorry if so). >>> >>> I think we should have a new iv for just the doloop (which can have the >>> same starting value and step and type as another iv). >>> >>> Has this been considered? >> >> I was also suggesting this (maybe with too many words ;)). If >> it's a doloop target add such IV (candidate!) which has zero >> use-cost for the increment and compare but a (target configurable) >> penalty for other uses. Invasiveness of this approach is probably >> that you need to distinguish this candidate by making it a new >> kind (or maybe we can just have a specia candidate number...). > > Or just set some (boolean) flag in the candidate. > > I think it should simply not be allowed for any use except the doloop > uses at all?
For the targets where the iteration count doesn't sit in its hardware count register, we may need to allow the IV to be used for other suitable uses? > You can have multiple ivs for the same loop just fine, > right? Yes. > And costs will make everything work out, if the costs are set > correctly? There are some cases requiring to do IV elimination, it might require some cost adjustment/tuning to keep this. I met this when I did pre-bind the BIV for it, if the dedicated IV has the best cost and is associated to doloop use, it probably stops the others to merge. If my understanding is correct, this is more like to transform the loop into doloop pattern earlier, the penalty of mis-predication of doloop can be more? Pros is the setup code sequence for iteration count happens in middle-end, can be optimized better (RTL misses some range info).
