<html>
<head>
<base href="https://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 --- - New verifier complaining about bad TBAA metadata created during hoist-merge optimization"
href="https://llvm.org/bugs/show_bug.cgi?id=31393">31393</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>New verifier complaining about bad TBAA metadata created during hoist-merge optimization
</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>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>Scalar Optimizations
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>Kevin.Harris@unisys.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=17760" name="attach_17760" title="Bitcode example file">attachment 17760</a> <a href="attachment.cgi?id=17760&action=edit" title="Bitcode example file">[details]</a></span>
Bitcode example file
In revs 289402 & 289403 (9-Dec-16), a new TBAA verifier was introduced. This
new verifier detected a problem with TBAA nodes that are initially OK, but,
after multiple loads or stores are hoisted out of a loop and merged, no longer
pass verification. Here's an example of the messages produced:
kharris@cm-mariner35:~/dyntrans/Tests/regression> $LLVMPATH/opt -O2 -o
if200014004000_1-o.bc if200014004000_1.bc
Access type node must be scalar
%grsval = load i64, i64* %saddr266, align 8, !tbaa !47
!47 = !{!2, !2, i64 0}
!2 = !{!3, !3, i64 0}
Access type node must be scalar
store i64 %mem_grs271, i64* %daddr267, align 8, !tbaa !47
!47 = !{!2, !2, i64 0}
!2 = !{!3, !3, i64 0}
LLVM ERROR: Broken function found, compilation aborted!
The original code has been working for several years. Historically, when two
loads with different TBAA metadata values are merged, the metadata for the
merged node is the common root of the originals. The new code appears to
attempt to hold on to both original values (noble), but the new verifier
rejects this structure. It isn't obvious whether the fix lies in the verifier
or in the merging code, since removing the verification causes a downstream
crash.
We applaud the effort (since reverting to the root node causes the merged load
to potentially interfere with unrelated memory addresses), but not at the
expense of the ability to generate usable code.
We would really appreciate it if this problem could be fixed in time for the
4.0 release.</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>