<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 - Potential incorrect generation of store-pair"
href="https://bugs.llvm.org/show_bug.cgi?id=32323">32323</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Potential incorrect generation of store-pair
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Backend: AArch64
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>pirama@google.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=18119" name="attach_18119" title="files to reproduce issue">attachment 18119</a> <a href="attachment.cgi?id=18119&action=edit" title="files to reproduce issue">[details]</a></span>
files to reproduce issue
This is an issue reported internally within Android. At a high level, until
r276451, two stores incorrectly got merged into a 'stp' despite there being an
aliasing write between the first store and the merged 'stp'. This issue goes
away with r276452
(<a href="http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160718/375442.html">http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160718/375442.html</a>).
But it's not clear if this revision indirectly fixes the underlying issue or
if it just masks a bug in the backend.
Here's the original bug report:
===============================
This turned up compiling vulkan validation layer tests.
Some tests had bad fields in structs despite source code that initialized them.
The reduced test case shows the fields being initialized and then overwritten.
The problem can be masked by explicitly initializing another field.
These assignments are implemented as a store of 7 into a stack address at
[sp,#44] and 1 into [sp,#48].
descriptorset_layout_binding.descriptorType =
VK_DESCRIPTOR_TYPE_STORAGE_BUFFER;
descriptorset_layout_binding.descriptorCount = 1;
The problem can be masked by explicitly initializing another field in line 120.
That changes the code generated for line 126 and line 115.
115 VkDescriptorSetLayoutBinding descriptorset_layout_binding = {};
116 descriptorset_layout_binding.descriptorType =
VK_DESCRIPTOR_TYPE_STORAGE_BUFFER;
117 descriptorset_layout_binding.descriptorCount = 1;
118 descriptorset_layout_binding.stageFlags = VK_SHADER_STAGE_ALL;
119 #ifdef FIX
120 descriptorset_layout_binding.pImmutableSamplers = nullptr;
121 #endif
122
123 VkDescriptorSetLayoutCreateInfo descriptorset_layout_create_info = {};
124 descriptorset_layout_create_info.sType =
VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_CREATE_INFO;
125 descriptorset_layout_create_info.bindingCount = 1;
126 descriptorset_layout_create_info.pBindings =
&descriptorset_layout_binding;
The attached testit.sh script shows the difference between code compiled with
and without the workaround.
The diff makes it a little easier to see what goes wrong.
The value at [sp,#44] is overwritten with zero by a stp x8,xzr,[sp,#32].
That instruction is supposed to be writing to [sp,#32] in a neighboring struct.
It seems to also be trying to zero out four bytes at [sp,#40]. But it clobbers
[sp,#44].
descriptorset_layout_create_info.pBindings = &descriptorset_layout_binding;
- .loc 1 126 48 // t.cpp:126:48
- str x8, [sp, #32]
+ .loc 1 115 34 discriminator 1 // t.cpp:115:34
+ stp x8, xzr, [sp, #32]
The version with workaround is marked as "-".
The broken version is marked as "+".</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>