[PATCH] D49097: [RegisterCoalescer] Another fix for subrange join unreachable

[Matthias Braun via Phabricator via llvm-commits]

MatzeB added a comment.

In https://reviews.llvm.org/D49097#1213446, @tpr wrote:

> This fix adds code to scan all uses of a subrange and extend it, after every join. I can't think of a way of doing it in a lower impact way.
>
> Which has got me thinking:
>
> Am I right about all of the following?
>
> 1. The decision on whether to join a copy is taken only with reference to each register's main range, not the subrange.


Yes.

> 2. The only reason it does similar stuff with conflict detection and resolution on the subranges is so it can modify them incrementally.

Yes, it's mostly about updating the subranges.

> 3. This fix, scanning all uses and extending subranges after a join, pretty much nullifies the advantage of modifying subranges incrementally.

Two reasons:

1. Updating the liveranges was considered better for compiletime (I mean you could remove even the non-subrange updating logic with the same reasoning to make the code even simpler...)
2. Recalculating subregister liveness used to not work reliably after coalescing (There were corner cases with full register uses with only some lanes being defined, without having corresponding IMPLICIT_DEF instructions for the undefined lanes).

> If so, why not remove all the code that incrementally modifies subranges, and instead remove the subranges of any register affected by a join, and recalculate them from scratch at the end of the whole pass? That would simplify the code, and we have found quite a few bugs in the way that subranges are incrementally modified.

I agree that the current code is highly complex and I don't like that either. I tried recalculating everything a couple years ago and could not get that working because of the recalculation problems, however it may be worth trying it again as the `Undefs` arrays passed around in LiveRangeCalc should/may fix all the problems in that area. Would be nice to see some experiments if we get the same liveness information as before when recalculating and how it would affect compile time...


Repository:
  rL LLVM

https://reviews.llvm.org/D49097