On 11/19/2017 07:46 AM, Jan Hubicka wrote: > Hi, > my understanding of the code is that trip_count is trying to estimate number > of iterations when counts are available and disable modulo scheduler for > loops with too few iterations. That's my reading as well.
> We now have get_estimated_loop_iterations_int and get_max_loop_iterations_int > which keeps information detected upstream and so we should use i there. > > I tested the patch very lightly only on the testcase in question as I am not > sure when and how modulo sched is used. I don't think it's enabled anywhere by default. IIRC it was primarily used on ia64, though my recollection is also that they group that did the work also saw good gains on ppc. I still think we need to do some kind of evaluation about whether or not to keep that code. If it's not being used, then it's just a maintenance burden. > > Seems sane? What are the code size impacts of modulo scheduling? Given it's a software pipelining algorithm I'd expect it expands code, consistently :-) But it's probably less than loop unrolling in general. > > Honza > > PR 82849 > * modulo-sched.c (sms_schedule): Use get_estimated_loop_iterations_int > and get_max_loop_iterations_int. Seems reasoanble. I'd go with it. jeff
