On Tue, Feb 11, 2020 at 08:34:15AM +0100, Richard Biener wrote: > On Mon, 10 Feb 2020, Segher Boessenkool wrote: > > Yes, we should decide how often we want to unroll things somewhere before > > ivopts already, and just use that info here. > > > > Or are there advantage to doing it *in* ivopts? It sounds like doing > > it there is probably expensive, but maybe not, and we need to do similar > > analysis there anyway. > > Well, if the only benefit of doing the unrolling is that IVs get > cheaper then yes, IVOPTs should drive it.
We need to know much earlier in the pass pipeline how often a loop will be unrolled. We don't have to *do* it early. If we want to know it before ivopts, then obviously it has to be done earlier. Otherwise, maybe it is a good idea to do it in ivopts itself. Or maybe not. It's just an idea :-) We know we do not want it *later*, ivopts needs to know this to make good decisions of its own. > But usually unrolling exposes redundancies (catched by predictive > commoning which drives some unrolling) or it enables better use > of CPU resources via scheduling (only catched later in RTL). > For scheduling we have the additional complication that the RTL > side doesn't have as much of a fancy data dependence analysis > framework as on the GIMPLE side. So I'd put my bet on trying to > move something like SMS to GIMPLE and combine it with unrolling > (IIRC SMS at most interleaves 1 1/2 loop iterations). SMS on RTL always was quite disappointing... Do you expect it will be more useful on Gimple? Moving it there is a good idea in any case ;-) I don't quite see the synergy between SMS and loop unrolling, but maybe I need to look harder. Segher
