https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288
--- Comment #12 from amker at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #11) > But the RTL loop optimizers just notice that the BIV has a step of 16 and > divides the expression, I think we can't expect those passes to be able to > use combine-like simplifications.81082 > > Another possibility is, if it is easy to predict what loops would be very > likely candidates for doloop if the target supports them force for them in > IVOPTS an IV with step of 1 (or -1), rather than some other step (and use > that IV solely for the loop condition), plus use a IV with the other step if > needed; with the expectation that doloop optimizes such IVs away completely > and just uses the initial value for initializing the loop counter. Yes, so far we only decrease cost by 1 IIRC if IV can terminate at ZERO. That means, we don't cancel all the IV cost. The issue is we don't model what loop is "how" likely be candidates for doloop on TREE level. A task for targets which support doloop? :) Patch always welcome.
