[llvm-bugs] [Bug 27612] New: Incorrect code when hoist spill to a BB with landingpad successor

via llvm-bugs llvm-bugs at lists.llvm.org
Mon May 2 22:35:03 PDT 2016


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

            Bug ID: 27612
           Summary: Incorrect code when hoist spill to a BB with
                    landingpad successor
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Register Allocator
          Assignee: unassignedbugs at nondot.org
          Reporter: wmi at google.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 16296
  --> https://llvm.org/bugs/attachment.cgi?id=16296&action=edit
testcase 1.cc

We had an internal test SEGV after r266162. A testcase 1.cc was extracted and
attached.

~/workarea/llvm-r266162/dbuild/bin/clang++ -std=c++11 -fPIC
-fsanitize=address,bool,float-cast-overflow,integer-divide-by-zero,return,returns-nonnull-attribute,shift-exponent,unreachable,vla-bound
-fno-sanitize-recover=all -O1 -S 1.cc

The following code was problematic:

        xorl    %edi, %edi
        callq   _ZlsIiEv1CIT_Ej at PLT
.Ltmp2:
        movq    %r12, 24(%rbx)          # 8-byte Spill
# BB#5:

_ZlsIiEv1CIT_Ej at PLT was a func which may throw. Before hoisting, Spill (movq   
%r12, 24(%rbx)) existed in both fall through code and landingpad of callq  
_ZlsIiEv1CIT_Ej at PLT. It is incorrect to insert Spill after the call during
hoisting.  

When we hoist spill to a BB with landingpad successor, if the live interval of
the spill reg live into the landingpad successor, the spill should be inserted
before the last split point, i.e., before the call that may throw.

Will send out a patch for review soon.

-- 
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/20160503/820de435/attachment.html>


More information about the llvm-bugs mailing list