[LLVMbugs] [Bug 21265] New: EFLAGS can end up as a live-out and crash stackmaps

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=21265

            Bug ID: 21265
           Summary: EFLAGS can end up as a live-out and crash stackmaps
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: kmod at dropbox.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13198
  --> http://llvm.org/bugs/attachment.cgi?id=13198&action=edit
Test code -- run "llc eflags.ll" to reproduce

I've run into a situation where EFLAGS can end up as a live-out; here's a
snippet of the code before doing a block-merging optimization in
BranchFolding.cpp:

BB#1: derived from LLVM BB %1
    Live Ins: %RBP
    Predecessors according to CFG: BB#0
        %EAX<def> = MOV32r0 %EFLAGS<imp-def,dead>
        TEST8rr %AL, %AL, %EFLAGS<imp-def>, %EAX<imp-use,kill>
        JNE_4 <BB#4>, %EFLAGS<imp-use,kill>
        JMP_4 <BB#4>
    Successors according to CFG: BB#4(1048576)

BB#4: derived from LLVM BB %5
    Live Ins: %RBP
    Predecessors according to CFG: BB#1
        PATCHPOINT 30702560, 13, 8383728, 0, 0, <regmask>, %RSP<imp-def>,
%RAX<imp-def,dead>, ...
        %RBP<def> = POP64r %RSP<imp-def>, %RSP<imp-use>
        RETQ


First we remove the extraneous JNE and JMP in BB#1:

BB#1: derived from LLVM BB %1
    Live Ins: %RBP
    Predecessors according to CFG: BB#0
        %EAX<def> = MOV32r0 %EFLAGS<imp-def,dead>
        TEST8rr %AL, %AL, %EFLAGS<imp-def>, %EAX<imp-use,kill>
    Successors according to CFG: BB#4(1048576)

BB#4: derived from LLVM BB %5
    Live Ins: %RBP
    Predecessors according to CFG: BB#1
        PATCHPOINT 30702560, 13, 8383728, 0, 0, <regmask>, %RSP<imp-def>,
%RAX<imp-def,dead>, ...
        %RBP<def> = POP64r %RSP<imp-def>, %RSP<imp-use>
        RETQ


Then BB#4 gets merged in, resulting in this:

BB#1: derived from LLVM BB %1
    Live Ins: %RBP
    Predecessors according to CFG: BB#0
        %EAX<def> = MOV32r0 %EFLAGS<imp-def,dead>
        TEST8rr %AL, %AL, %EFLAGS<imp-def>, %EAX<imp-use,kill>
        PATCHPOINT 30702560, 13, 8383728, 0, 0, <regmask>, %RSP<imp-def>,
%RAX<imp-def,dead>, ...
        %RBP<def> = POP64r %RSP<imp-def>, %RSP<imp-use>
        RETQ



In the removing of the JNE, we got rid of the instruction that kills EFLAGS,
without changing the TEST8rr instruction to mark it as a dead def.  Then when
we calculate liveness for the patchpoint, it looks like EFLAGS is supposed to
be alive there, tripping an assert in the stackmaps code.  I'm not sure if
anything else is affected by this, since it happens pretty late in the
pipeline.



Not sure if this is related to http://llvm.org/bugs/show_bug.cgi?id=11132 --
seems like a similar result but might happen differently?

-- 
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/20141013/f40d4907/attachment.html>