[llvm-bugs] [Bug 38907] New: "Bad machine code: Multiple connected components in live interval" after simple-register-coalescing

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=38907

            Bug ID: 38907
           Summary: "Bad machine code: Multiple connected components in
                    live interval" after simple-register-coalescing
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: mikael.holmen at ericsson.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 20868
  --> https://bugs.llvm.org/attachment.cgi?id=20868&action=edit
reproducer

If I remove the preservation of LiveIntervals in the coalescer (i.e. I comment
out AU.addPreserved<LiveIntervals>();) then the verifier complains about

*** Bad machine code: Multiple connected components in live interval ***

when I do

llc -O1 -o - foo_amd.mir -verify-machineinstrs -start-before
simple-register-coalescing -march=amdgcn

In a way it's a silly case of "if I do a stupid thing in the coalescer, then
something goes wrong" but really, should things fail if I remove an
addPreserved call?

So, if I remove

AU.addPreserved<LiveIntervals>();

from RegisterCoalescer::getAnalysisUsage then the following testcase

# RUN: llc -O1 -o - %s -verify-machineinstrs -start-before
simple-register-coalescing -march=amdgcn
---
name:            f3
tracksRegLiveness: true
frameInfo:
body:             |
  bb.0:
    successors: %bb.1(0x80000000)

    %5:sreg_32 = IMPLICIT_DEF
    S_BRANCH %bb.1

  bb.1:
    successors: %bb.3(0x40000000), %bb.2(0x40000000)

    %6:sreg_32 = COPY killed %5
    S_CBRANCH_SCC0 %bb.3, implicit undef $scc

  bb.2:
    successors: %bb.3(0x80000000)

    %6:sreg_32 = IMPLICIT_DEF
    S_BRANCH %bb.3

  bb.3:
    successors: %bb.1(0x80000000)

    %5 = COPY killed %6
    S_BRANCH %bb.1
...

gives me

# After Rename Disconnected Subregister Components
********** INTERVALS **********
%1 [16r,16d:0)[112r,112d:1)  0 at 16r 1 at 112r weight:0.000000e+00
RegMasks:
********** MACHINEINSTRS **********
# Machine code for function f3: NoPHIs, TracksLiveness

0B      bb.0:
          successors: %bb.1(0x80000000); %bb.1(100.00%)

16B       dead %1:sreg_32 = IMPLICIT_DEF
32B       S_BRANCH %bb.1

48B     bb.1:
        ; predecessors: %bb.0, %bb.3
          successors: %bb.3(0x40000000), %bb.2(0x40000000); %bb.3(50.00%),
%bb.2(50.00%)

80B       S_CBRANCH_SCC0 %bb.3, implicit undef $scc

96B     bb.2:
        ; predecessors: %bb.1
          successors: %bb.3(0x80000000); %bb.3(100.00%)

112B      dead %1:sreg_32 = IMPLICIT_DEF
128B      S_BRANCH %bb.3

144B    bb.3:
        ; predecessors: %bb.1, %bb.2
          successors: %bb.1(0x80000000); %bb.1(100.00%)

176B      S_BRANCH %bb.1

# End machine code for function f3.

*** Bad machine code: Multiple connected components in live interval ***
- function:    f3
- interval:    %1 [16r,16d:0)[112r,112d:1)  0 at 16r 1 at 112r weight:0.000000e+00
0: valnos 0
1: valnos 1
LLVM ERROR: Found 1 machine code errors.

If I don't remove the addPreserved, then the %1 definitions are not marked
"dead" and the intervals become

%1 [16r,48B:3)[48B,96B:1)[112r,144B:0)[144B,192B:2)  0 at 112r 1 at 48B-phi
2 at 144B-phi 3 at 16r weight:0.000000e+00

instead of

%1 [16r,16d:0)[112r,112d:1)  0 at 16r 1 at 112r weight:0.000000e+00

and the verifier doesn't complain.

(In my out-of-tree target we run a pass after the coalescer that does not
preserve LiveIntervals, so it needs to be rerun and then the "dead" markings
are introduced, which later makes the verifier complain. So we actually run
into real problems like this without having to hack the coalescer.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180912/3b8b2591/attachment-0001.html>