[LLVMbugs] [Bug 16095] New: StackColoring can wrongly merge stack slots: marker semantics poorly defined

[bugzilla-daemon at llvm.org]

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

            Bug ID: 16095
           Summary: StackColoring can wrongly merge stack slots: marker
                    semantics poorly defined
           Product: tools
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
          Assignee: unassignedbugs at nondot.org
          Reporter: mseaborn at chromium.org
                CC: llvmbugs at cs.uiuc.edu, nrotem at apple.com
    Classification: Unclassified

LLVM's StackColoring pass wrongly merges the stack slots %buf1 and %buf2 in the
following example:

declare void @llvm.lifetime.start(i64, i8*)
declare void @llvm.lifetime.end(i64, i8*)
declare void @ext_func(i8*)

define void @mycall(i8* %addr) {
  %buf1 = alloca i8, i32 100000
  %buf2 = alloca i8, i32 100000

  ; If the alloca reference is sufficiently deeply nested,
  ; GetUnderlyingObject() won't look through it.
  %buf2_cast1 = bitcast i8* %buf2 to i8*
  %buf2_cast2 = bitcast i8* %buf2_cast1 to i8*
  %buf2_cast3 = bitcast i8* %buf2_cast2 to i8*
  %buf2_cast4 = bitcast i8* %buf2_cast3 to i8*
  %buf2_cast5 = bitcast i8* %buf2_cast4 to i8*
  %buf2_cast6 = bitcast i8* %buf2_cast5 to i8*
  %buf2_cast7 = bitcast i8* %buf2_cast6 to i8*

  call void @llvm.lifetime.start(i64 -1, i8* %buf2)
  call void @llvm.lifetime.end(i64 -1, i8* %buf2)
  ; lifetime.end(%buf2) means that %buf2 is dead here.

  call void @llvm.lifetime.start(i64 -1, i8* %buf1)
  call void @ext_func(i8* %buf1)

  call void @llvm.lifetime.start(i64 -1, i8* %buf2_cast7)

  ; Both %buf1 and %buf2 are live at this point, but StackColoring
  ; will wrongly regard %buf2 as dead and merge it with %buf1.
  call void @ext_func(i8* %buf2)

  ret void
}


Actual output:

$ llc -mtriple=x86_64-none-gnu stack-coloring.ll -o -
...
        subq    $100008, %rsp           # imm = 0x186A8
...

Expected output, which also occurs if we change the last lifetime.start() to
use %buf2_cast6 instead of %buf2_cast7:

$ llc -mtriple=x86_64-none-gnu stack-coloring.ll -o -
...
        subq    $200008, %rsp           # imm = 0x30D48
...

This happens because SelectionDAGBuilder uses GetUnderlyingObjects() to find
the alloca instructions that a lifetime.start() or end() call refers to.  But
GetUnderlyingObjects() has a default MaxLookup limit of 6.

As a result, StackColoring only sees a subset of the lifetime markers.  But
ignoring subsets of the lifetime markers is not safe in general, because a
lifetime.start marker counteracts the effect of a lifetime.end marker (as
above), and vice versa.

The semantics of lifetime.start/end currently aren't very well defined.  The
LLVM Language Reference doesn't specify whether bitcasts/GEPs/PHIs of allocas
are valid arguments to lifetime.start/end.  Given that this affects the
safeness of the StackColoring, this should probably be fixed.

-- 
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/20130521/57a1d956/attachment.html>