<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - StackColoring can wrongly merge stack slots: marker semantics poorly defined"
href="http://llvm.org/bugs/show_bug.cgi?id=16095">16095</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>StackColoring can wrongly merge stack slots: marker semantics poorly defined
</td>
</tr>
<tr>
<th>Product</th>
<td>tools
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>llc
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>mseaborn@chromium.org
</td>
</tr>
<tr>
<th>CC</th>
<td>llvmbugs@cs.uiuc.edu, nrotem@apple.com
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>