<html>
<head>
<base href="https://bugs.llvm.org/">
</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 - -fast-isel=0 for armv7 can result in 4-byte Reload without corresponding 4-byte Spill"
href="https://bugs.llvm.org/show_bug.cgi?id=39714">39714</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>-fast-isel=0 for armv7 can result in 4-byte Reload without corresponding 4-byte Spill
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>7.0
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Macintosh
</td>
</tr>
<tr>
<th>OS</th>
<td>MacOS X
</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>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>jholajter@arxan.com
</td>
</tr>
<tr>
<th>CC</th>
<td>htmldeveloper@gmail.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=21130" name="attach_21130" title="repro.ll can be use to reproduce the incorrect assembly generated by llc">attachment 21130</a> <a href="attachment.cgi?id=21130&action=edit" title="repro.ll can be use to reproduce the incorrect assembly generated by llc">[details]</a></span>
repro.ll can be use to reproduce the incorrect assembly generated by llc
The attached test case demonstrates an issue where lowering armv7 bitcode for
iOS using -fast-isel=0 results in a register being reloaded from the stack
without first being spilled to the stack. This results in an unknown value
being loaded into the register and undefined runtime results.
This bug is important because Apple forces use of -fast-isel=0 when re-lowering
armv7 bitcode built using Enable Bitcode set to Yes. There is no way to disable
use of -fast-isel=0 when submitting bitcode to Apple.
Use the following command line with the attached repro.ll:
llc -relocation-model=pic -O0 -fast-isel=0 repro.ll -filetype=asm -o repro.s
The resultant repro.s will contain the following line:
ldr.w r1, [r6, #2500] @ 4-byte Reload
The reload of r1 with r6 offset by #2500 was never spilled to the stack. This
instruction is reading and unknown value from the stack and populating r1 with
it. This leads to undefined runtime behavior.
>From the repro.ll file, you can see that a function named printAggregate() is
being invoked:
call void @printAggregate(%struct.structOfStrings* byval align 4
@structOfStrings2, i32 2) #18
call void @printAggregate(%struct.structOfStrings* byval align 4
@structOfStrings1, i32 1) #18
call void @printAggregate(%struct.structOfStrings* byval align 4
@structOfStrings3, i32 3) #18
In the repro.s file, prior to the first invocation of printAggregate() we can
see that the second parameter is populated into r1 via the following
instruction:
movs r1, #2
This is also the case with the third invocation of printAggregate():
movs r1, #3
It is unclear why the second invocation of printAggregate() does not also use
movs, instead trying to Reload r1 from the stack even though it was never
spilled.</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>