[LLVMbugs] [Bug 17719] New: Greedy Register Allocator Incorrectly Reusing A FixStack Slot Because Of SjLj

[bugzilla-daemon at llvm.org]

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

            Bug ID: 17719
           Summary: Greedy Register Allocator Incorrectly Reusing A
                    FixStack Slot Because Of SjLj
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Register Allocator
          Assignee: unassignedbugs at nondot.org
          Reporter: manjian2006 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 11437
  --> http://llvm.org/bugs/attachment.cgi?id=11437&action=edit
source to upload

In the uploaded sources:
            if (sizeOnly ? decoder->ImageDecoder::isSizeAvailable() :
decoder->isComplete())
ecoder->isComplete() is inline combined with
        bool isComplete() const
        {
            return !m_frameBufferCache.isEmpty() &&
(m_frameBufferCache.first().status() == ImageFrame::FrameComplete);
m_frameBufferCache.isEmpty() is inline combined with 

    bool isEmpty() const { return !size(); }


and becomes a while pre-header
while.body.lr.ph:                                 ; preds = %79
  %m_currentBufferSize = getelementptr inbounds
%"class.WebCore::PNGImageReader"* %this, i32 0, i32 6
  %m_info = getelementptr inbounds %"class.WebCore::PNGImageReader"* %this, i32
0, i32 3
  %83 = getelementptr inbounds i8* %call, i32 72
  %m_size.i.i.i = getelementptr inbounds i8* %call, i32 8



and after ISel and Live Variable Analysis
BB#18: derived from LLVM BB %while.body.lr.ph
    Predecessors according to CFG: BB#16
    %vreg12<def,tied1> = ADD32ri8 %vreg10<tied0>, 12, %EFLAGS<imp-def,dead>;
GR32:%vreg12,%vreg10
    %vreg13<def,tied1> = ADD32ri8 %vreg10<tied0>, 74, %EFLAGS<imp-def,dead>;
GR32:%vreg13,%vreg10
    %vreg15<def> = COPY %vreg101<kill>; GR32:%vreg15,%vreg101
    %vreg16<def,tied1> = ADD32ri8 %vreg42<tied0>, 24, %EFLAGS<imp-def,dead>;
GR32:%vreg16,%vreg42
    %vreg17<def,tied1> = ADD32ri8 %vreg42<tied0>, 12, %EFLAGS<imp-def,dead>;
GR32:%vreg17,%vreg42
    %vreg18<def,tied1> = ADD32ri8 %vreg10<tied0>, 72, %EFLAGS<imp-def,dead>;
GR32:%vreg18,%vreg10
    %vreg19<def,tied1> = ADD32ri8 %vreg10<kill,tied0>, 8,
%EFLAGS<imp-def,dead>; GR32:%vreg19,%vreg10
    %vreg147<def> = MOV32ri 128; GR32:%vreg147


We can see our vreg10 is considered killed.And that's correct,because the auto
variable decoder is really not used any longer.

But the greedy register allocator thinks the slot using by "decoder" can be
reused.So after  Virtual Register Rewriter


2832B    BB#18: derived from LLVM BB %while.body.lr.ph
        Live Ins: %EAX %EBX %ESI
        Predecessors according to CFG: BB#16
2840B        %EDI<def> = MOV32rm <fi#4>, 1, %noreg, 0, %noreg;
mem:LD4[FixedStack4]
2848B        %ECX<def> = LEA32r %EDI, 1, %noreg, 12, %noreg
2856B        MOV32mr <fi#9>, 1, %noreg, 0, %noreg, %ECX<kill>;
mem:ST4[FixedStack9]
2864B        %ECX<def> = LEA32r %EDI, 1, %noreg, 74, %noreg
2872B        MOV32mr <fi#10>, 1, %noreg, 0, %noreg, %ECX<kill>;
mem:ST4[FixedStack10]
2896B        %ECX<def> = LEA32r %ESI, 1, %noreg, 24, %noreg
2904B        MOV32mr <fi#11>, 1, %noreg, 0, %noreg, %ECX<kill>;
mem:ST4[FixedStack11]
2912B        %ECX<def> = LEA32r %ESI, 1, %noreg, 12, %noreg
2920B        MOV32mr <fi#12>, 1, %noreg, 0, %noreg, %ECX<kill>;
mem:ST4[FixedStack12]
2928B        %ECX<def> = LEA32r %EDI, 1, %noreg, 72, %noreg
2936B        MOV32mr <fi#13>, 1, %noreg, 0, %noreg, %ECX<kill>;
mem:ST4[FixedStack13]
2960B        %EDI<def,tied1> = ADD32ri8 %EDI<kill,tied0>, 8,
%EFLAGS<imp-def,dead>
2968B        MOV32mr <fi#4>, 1, %noreg, 0, %noreg, %EDI<kill>;
mem:ST4[FixedStack4]

we can see %m_size.i.i.i is spilled to decoder's spill location.


After longjmp is called,the control flow goes to setjmp block,
which will access %m_size.i.i.i 's address as decoder's



The uploaded archive contains  the sources and the compile script.
You may compile the source like this:
bash 1.sh

-- 
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/20131029/fb68debc/attachment.html>