on 2021/1/26 上午4:37, Segher Boessenkool wrote: > Hi! > > On Mon, Jan 25, 2021 at 05:59:23PM +0000, Richard Sandiford wrote: >> Richard Biener <rguent...@suse.de> writes: >>> On Fri, 22 Jan 2021, Segher Boessenkool wrote: >>>> But what could have been done differently that would have helped? Of >>>> course Ke Wen could have written a better patch (aka one that is more >>>> acceptable); either of you could have made your current replies earlier, >>>> so that it is clear help needs to be sought elsewhere; and I could have >>>> pushed people earlier, too. No one really did anything wrong, I'm not >>>> seeking who to blame, I'm just trying to find out how to prevent >>>> deadlocks like this in the future (where one party waits for replies >>>> that will never come). >>>> >>>> Is it just that we have a big gaping hole in reviewers with experience >>>> in such loop optimisations? >>> >>> May be. But what I think is the biggest problem is that we do not >>> have a good way to achieve what the patch tries (if you review the >>> communications you'll see many ideas tossed around) first and foremost >>> because IV selection is happening early on GIMPLE and unrolling >>> happens late on RTL. Both need a quite accurate estimate of costs >>> but unrolling has an ever harder time than IV selection where we've >>> got along with throwing dummy RTL at costing functions. > > GIMPLE already needs at least an *estimate* of how much any loop will > be unrolled (for similar reasons as the IV selection). The actual > mechanics can happen later (in RTL), and we could even use a different > unroll factor (in some cases) than what we first estimated; but for the > GIMPLE optimisations it can be important to know what the target code > will eventually look like. >
Yeah, this point was discussed/mentioned that the estimated result can be used for other passes too. But I'm not sure whether we have already known some other passes who suffer this kind of similar problem. BR, Kewen
