[LLVMbugs] [Bug 22439] New: MachineCSE adds bogosity to MachineOperand flags

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Mon Feb 2 18:28:31 PST 2015


            Bug ID: 22439
           Summary: MachineCSE adds bogosity to MachineOperand flags
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
          Assignee: unassignedbugs at nondot.org
          Reporter: grosbach at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Consider test/CodeGen/AArch64/arm64-cse.ll run under the machine verifier:

*** Bad machine code: Virtual register def doesn't dominate all uses. ***
- function:    t2
- basic block: BB#0 entry (0x7faeab8489b0)
- instruction: %vreg8<def,dead> = SUBSWri %vreg6, 1, 0, %NZCV<imp-def>;
GPR32:%vreg8 GPR32common:%vreg6
LLVM ERROR: Found 1 machine code errors.

This is complaining about:
BB#0: derived from LLVM BB %entry
    Live Ins: %X0 %X1
    %vreg8<def,dead> = SUBSWri %vreg6, 1, 0, %NZCV<imp-def>; GPR32:%vreg8
    Bcc 10, <BB#1>, %NZCV<imp-use>
    Successors according to CFG: BB#3(12) BB#1(20)

BB#1: derived from LLVM BB %if.end
    Predecessors according to CFG: BB#0
    STRWui %vreg8, %vreg4, 0; mem:ST4[%offset] GPR32:%vreg8 GPR64common:%vreg4

%vreg8 is marked as a dead def, but the store in BB#1 is using it.

That block used to have:
            %vreg9<def> = SUBSWri %vreg0, 1, 0, %NZCV<imp-def,dead>;
GPR32:%vreg9 GPR32sp:%vreg0
            STRWui %vreg9, %vreg4, 0; mem:ST4[%offset] GPR32:%vreg9

MachineCSE recognized that the SUBSWri can be deleted and the value from BB#0
used instead; however, it neglects to update the "dead" flag on %vreg8 when it
does so, and thus introduces bogusness.

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/20150203/0d5f66bd/attachment.html>

More information about the llvm-bugs mailing list