These conflicts can legitimately happen when merging registers where subregister definitions of one taint, but not invalidate the other. While the main range conflict resolution can deal with it, the subrange conflicts will remain due to the overlapping segments.
This should ideally have a .mir test with a minimum reproducer. Maybe it is possible to make an actual test out of the comment in the code (see for example the other .mir tests in the AMDGPU directory on how you can model nearly all situations by appending implicit defs/uses to NOP instructions).
I am trying to understand this, let's look at :sub1 for example: It is defined in 736 and read in 976, in that time :sub1 of vreg140 cannot be live or the join would be invalid. After that :sub1 is written in 1008 and read in 1248, in this time vreg131:sub1 cannot be live or the join would be invalid. I don't see an overlap in the subregisters here.
Sub1 may not be the best choice here. Consider sub2 instead: vreg140:sub2 is first defined in 704, then it is live until 1008 and subsequently overwritten in 1040. The live subrange for it will be [704,1008)[1040,1248). This will overlap with the live range for vreg131:sub2. The join of vreg131 and vreg140 is valid, since all the lanes written via vreg131:subN = COPY ... are never actually used via vreg140:subN. They are considered "used" for the purpose of liveness tracking, but are not actually used by the program. The function resolveConflicts checks specifically for that (via taintExtent and usesLanes).
I would not expect the example in the comment to pass the usesLanes checks because of the lack of undef flags, right?
But if they are alive that means they are used right? I mean we couldn't merge them unless vreg140:sub1 has read-undef, could we?
Basically, I don't like us making assumptions on what the liveness models compared to what the program actually uses. I am afraid it may work for some targets, but not all of them. Therefore, I would rather be conservatively correct (that we have right now) than guessing around the liveness.
The problem is somewhere else: live subranges should not be extended to other subregs' defs.
My previous comments are incorrect. The problem is in the fact that live subranges were extended to other subregs' defs. I will submit another patch that corrects that issue.