[llvm-dev] Assertion failure "There should be at least one conflict." in register coalescing

[Harald van Dijk via llvm-dev]

On 15/10/2019 12:16, Harald van Dijk via llvm-dev wrote:
>                    restoring liveness to 2 points: 64r,48r:  %0 
> [16r,48r:0)[48r,112d:1)  0 at 16r 1 at 48r weight:0.000000e+00
>[...]
> I am trying to understand what this all means, but one thing that
> strikes me is that if I manually update the MIR so that the first update
> has been performed already:
> 
>    name: f
>    body: |
>      bb.0:
>        %0:gr64_with_sub_8bit = COPY $rax
>        %1:gr32 = MOV32rr %0.sub_32bit:gr64_with_sub_8bit
>        %0.sub_32bit:gr64_with_sub_8bit = COPY %1:gr32
>        %3:gr32 = MOV32rr %0.sub_32bit:gr64_with_sub_8bit
>        %1:gr32 = MOV32rr %0.sub_32bit:gr64_with_sub_8bit
> 
> the pass does run successfully. However, the recalculated intervals are
> not identical to what they were thought to be after the first update:
> 
>    ********** INTERVALS **********
>    %0 [16r,48r:1)[48r,80r:0)  0 at 48r 1 at 16r weight:0.000000e+00
>    %1 [32r,48r:1)[80r,80d:0)  0 at 80r 1 at 32r weight:0.000000e+00
>    %2 [64r,64d:0)  0 at 64r weight:0.000000e+00
> 
> Note %0's [48r,80r:0) here, which was [48r,112d) after the initial
> update. The instruction at 112 was
> %0.sub_32bit:gr64_with_sub_8bit = COPY %2:gr32, which had been deleted.
> Could that be the problem, the interval referring to a deleted
> instruction?

The d in 112d is Slot_Dead, which is documented as:

/// Dead def kill point.  Kill slot for a live range that is defined by
/// the same instruction (Slot_Register or Slot_EarlyClobber), but isn't
/// used anywhere.
Slot_Dead,

That seems very wrong: the value defined here is not dead.

> Cheers,
> Harald van Dijk