<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 - Function has 8 identical return blocks"
href="https://bugs.llvm.org/show_bug.cgi?id=38541">38541</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Function has 8 identical return blocks
</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>Common Code Generator Code
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>paulsson@linux.vnet.ibm.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=20687" name="attach_20687" title="clang test case">attachment 20687</a> <a href="attachment.cgi?id=20687&action=edit" title="clang test case">[details]</a></span>
clang test case
For some reason, the attached function (unreduced from SPEC), ends up with 8
identical return blocks:
.LBB0_29:
mvi 160(%r2), 1
lgfr %r2, %r0
lmg %r6, %r15, 48(%r15)
br %r14
.LBB0_30:
mvi 160(%r2), 1
lgfr %r2, %r0
lmg %r6, %r15, 48(%r15)
br %r14
...
This function was unrolled 8 times at the source level by the programmer.
Each MVI (Move Immediate) have identical register and immediate operands, but
the memory operands refer to different Values.
The SystemZ implementation of areMemAccessesTriviallyDisjoint() would not
return true in this case, as it only looks at the memory operands currently.
But implementing this does not seem to help or even get called with the MVIs in
this case. I suppose the CFG optimizer is already checking for identical
operands...
I am not sure how important this is, but unless I am missing something it seems
like an obvious case of improvement since one such return block should be
enough.
The Control Flow optimizer sees 8 identical blocks with just MVI + J:
MVI killed renamable $r2d, 160, 1
J %bb.36
These are conditionally jumped over blocks, each preceded with a BRC to the
block immediately after it. So it seems that CFGOpt thinks it's a good idea to
conditionally jump past them, instead of conditionally jumping to one such
block (this is in itself a bit confusing to me, since I thought that generally
NT branches are preferred).
Only after Branch Probability Basic Block Placement have %bb.36 been inlined
into each such block, giving the blocks per above. I'm a bit confused since
judging from the name BB Placement shouldn't alter anything, or is some other
pass running also here?
Curious to hear what anybody has to say about this, and if there is anything in
the SystemZ backend that could be improved to help cases like this?
clang -cc1 -triple s390x-ibm-linux -S -target-cpu z13 -O3 -o out.s -x ir
./tc_8retblocks.bc</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>