Hi Vlad, Vladimir Makarov <vmaka...@redhat.com> writes: > On 2022-01-06 09:47, Richard Sandiford wrote: >> Suppose that: >> >> - an inner loop L contains an allocno A >> - L clobbers hard register R while A is live >> - A's parent allocno is AP >> >> Previously, propagate_allocno_info would propagate conflict sets up the >> loop tree, so that the conflict between A and R would become a conflict >> between AP and R (and so on for ancestors of AP). > My thoughts for propagating hard register conflicts was to avoid > changing allocations on the region border as much as possible. The > solution you are proposing might result in allocating R to the allocno > and creating moves/loads/stores on the region border when it would be > possible to assign R to another allocno and another hard reg to the > allocno in consideration. As it is all about heuristics it is hard to > say just speculating what probability of such situation and what > heuristic is better. Only checking credible benchmarks is a criterium > to choose heuristics. […]
Yeah, I agree with all of the above. Any change to these heuristics is likely to make some things worse: a strict improvement over the status quo is essentially impossible. I guess in principle, the new heuristic is more suited to those high register pressure situations in which some spilling is inevitable. The cases that are most likely to lose out under the new heuristics are those where allocation is possible without spilling and where recording the conflicts gave the allocator the extra “push” it needed to prioritise the parent allocno over others with fewer subloop conflicts. And the risks of that happening are probably greater if the target is providing lop-sided costs. (Talking of which, the aarch64 port is still providing equal costs for loads and stores, which is something that we ought to look at. But again, it's a sensitive heuristic, so tweaking it will need care.) Thanks a lot for the quick reviews, really appreciate it. I've now pushed the series. Let's see what the fallout is :-) Richard
