https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #36 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 11 Oct 2019, wilco at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760 > > --- Comment #32 from Wilco <wilco at gcc dot gnu.org> --- > (In reply to Segher Boessenkool from comment #31) > > Gimple passes know a lot about machine details, too. > > > > Irrespective of if this is "low-level" or "high-level", it should be done > > earlier than it is now. It should either be done right after expand, or > > somewhere before it. Doing it in gimple seems easiest? > > Expand is way too late. Unrolling is high-level because it relies on other > high-level optimizations - for example to get addressing and induction > variables right. Without that it's always a loss. I know I've said it before but I really want to have a "GIMPLE unroller" integrated with a pass that can compute unrolling benefit. One candidate was of course IVOPTs which albeit is already quite complex but which has register pressure estimates and should have an idea how unrolling affects these. Computing unrolling benefit on its own would require some pipeline modeling on GIMPLE. So the other obvious candidiate would be the RTL scheduler - here I think SMS does "unrolling".
