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: [email protected]
Reporter: [email protected]
CC: [email protected]
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.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
