On Tue, 11 Jul 2023, Jan Hubicka wrote: > > > By now we did CCP and FRE so we likely optimized out most of constant > > > conditionals exposed by inline. > > > > So maybe we should simply delay re-propagation of the profile? I > > think cunrolli doesn't so much care about the profile - cunrolli > > is (was) about abstraction removal. Jump threading should be > > the first pass to care. > > That is what I was thinking too. After inlining the profile counts may > be in quite bad shape. If you inline together loop like in exchange that > has large loop nest, we will definitely end up capping counts to avoid > overflow. > > cunrolli does: > > ret = tree_unroll_loops_completely (optimize >= 3, false);
Ah, yeah - that used to be false, false ... > which sets may_increase_size to true for -O3 and then > > may_increase_size && optimize_loop_nest_for_speed_p (loop) > > which seems reasonable guard and it may get random answers on capped > profile. It is not big deal to try propagating before cunrolli and then > again before threading and see how much potential this idea has. > I guess I should also double check that the other passes are indeed > safe, but I think it is quite obvoius they should be. Yeah. Richard.
