On Tue, Jan 26, 2021 at 04:53:25PM +0800, Kewen.Lin wrote: > on 2021/1/26 上午4:37, Segher Boessenkool wrote: > > 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.
As concrete examples, look no further than everything vectorisation; but much more general, everything that chooses between multiple options, so almost *everything*, needs a good estimate of how expensive those options are. In all cases we are working on an highly idealised code representation (GIMPLE), but the actual costs are the costs of the machine code we eventually generate. In simple cases this isn't a big problem: A < 2A whenever A > 0, and A+2B < 2A+3B, and we even can reason without too much trouble that A+2B < 2A+B whenever B < A (everything > 0), but as soon as we have a slightly more complex situation (more variables, or not linear, etc.) things are much harder, and we really have to consider what code we eventually generate: it no longer can be abstracted away. IVOPTS does this. Various vectorisation things have to do this (I don't know how much is done currently, frantic waving of arms, but it is necessary to get good results). Anything that makes decisions that have a bigger effect on the generated machine code, but makes those decisions early, has to do it. One way is to look at the cost of representative RTL. Another way is to make a problem-specific model to estimate the costs. Both ways have their strengths and weaknesses. The first way is much more general. Segher
