[llvm-bugs] [Bug 39960] New: Incorrect liveness information after updating MBB live-ins through RDF

[via llvm-bugs]

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

            Bug ID: 39960
           Summary: Incorrect liveness information after updating MBB
                    live-ins through RDF
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Keywords: crash-on-invalid
          Severity: enhancement
          Priority: P
         Component: Backend: Hexagon
          Assignee: unassignedbugs at nondot.org
          Reporter: alexey.zhikhar at gmail.com
                CC: kparzysz at codeaurora.org, llvm-bugs at lists.llvm.org

Consider a case of an imaginary register R1 that is declared live-in in BB#1:

  BB#0:
    %R1 = define
    ...

  BB#1:
    Live Ins: %R1
    … = use %R1

Then, the code went through an RDF-based transformation, which lead to updating
live-ins of each basic block:

  BB#0:
    %R1 = define
    ...

  BB#1:
    Live Ins: %R0
    … = use %R1

But why do we have %R0 instead of %R1? One thing I didn't mention about this
imaginary processor is that R0 and R1 completely overlap with each other.
Nevertheless, the live-in information at this point is incorrect, which is
discovered by the machine instruction verifier.

My understanding of the reason behind this is that the data structure used by
rdf::Liveness:computeLiveIns() has a shortcoming: RegisterAggr stores register
units rather than registers, so loosing information is inevitable. Since R0 and
R1 share the same register unit, RDF picks the first register that corresponds
to the stored register unit.                                                    

Unfortunately, I cannot share the test case since it is written for our
out-of-tree backend; however, the bug should be relevant for each backend that
makes use of RDF.

-- 
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/20181211/b4c329db/attachment.html>