[PATCH] D35073: [RegisterCoalescer] Fix for subrange join unreachable

[David Stuttard via Phabricator via llvm-commits]

dstuttard added a comment.

In https://reviews.llvm.org/D35073#815414, @MatzeB wrote:

> I'm confused by this change (and the testcase doesn't really help understanding what is going on). You are probably onto a real bug here where we cannot assume the same lanemasks work for the input/output register class of a copy. However that should be independent of the fact that a full or partial copy is present.


Sorry about the test case. It isn't great, but that was the best I could do to provoke the error without spending a lot longer on it. The issue is provoked on the last 2 copies in the last BB (bb.25).

Having looked at what I've done again, I think you're correct that it isn't the right way to solve. Given the code before the change, it will never enter the subrange leg of the if as MI->isFullCopy() is always true at this point.

The issue that is showing up is that the LaneMask test for the subranges never results in a match in the loop over the subranges. This in turn leads to an assert shortly afterwards as the SubRange join never succeeds in any of the patterns being searched for in the JoinVals::computeAssignement method.

My initial attempt at a fix was the reasoning that since this if this is a fullcopy why do we need to match the subranges and pick the first matching one, they are all equally effective - now I realise that this is always the case, can't we always choose the same one as the non-subrange uses here?

Here's some info on the relevant registers and subranges:

  %vreg122 [448r,480B:1)[560B,992B:0)[992B,1040r:4)[1104r,1168B:2)[1824B,1888r:0)[2016r,2064B:3)  0 at 560B-phi 1 at 448r 2 at 1104r 3 at 2016r 4 at 992B-phi L00000009 [448r,448d:0)[992B,1040r:5)[1104r,1104d:1)[2016r,2064B:4)  0 at 448r 1 at 1104r 2 at x 3 at x 4 at 2016r 5 at 992B-phi L00000002 [448r,480B:1)[560B,992B:0)[992B,1040r:4)[1104r,1168B:2)[1824B,1872r:0)[2016r,2064B:3)  0 at 560B-phi 1 at 448r 2 at 1104r 3 at 2016r 4 at 992B-phi L00000004 [448r,480B:1)[560B,992B:0)[992B,1040r:4)[1104r,1168B:2)[1824B,1888r:0)[2016r,2064B:3)  0 at 560B-phi 1 at 448r 2 at 1104r 3 at 2016r 4 at 992B-phi
  
  %vreg126 [1872r,1888r:0)[1888r,2032r:1)  0 at 1872r 1 at 1888r L00000002 [1872r,2032r:0)  0 at 1872r L00000004 [1888r,2032r:0)  0 at 1888r
  
  %vreg151 [880r,992B:0)[992B,1104r:2)[2032r,2064B:1)  0 at 880r 1 at 2032r 2 at 992B-phi

In this case it's using the def of vreg151 against vreg122 in these 2 lines:

  2016B		%vreg122<def> = COPY %vreg126; VReg_128:%vreg122,%vreg126
  2032B		%vreg151<def> = COPY %vreg126; VReg_128:%vreg151,%vreg126

and in the valuesIdentical method it iterates over the vreg126 subranges (L000002 and L0000004) against the L000009 from vreg122 and doesn't match.

Perhaps using valuesIdentical with subranges is the issue here and an alternative should be implemented?


https://reviews.llvm.org/D35073