<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:orlando.hyams@sony.com" title="Orlando Cazalet-Hyams <orlando.hyams@sony.com>"> <span class="fn">Orlando Cazalet-Hyams</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [DebugInfo@O2][Dexter] Illegal value and unreachable lines seen when conditional stores merged"
href="https://bugs.llvm.org/show_bug.cgi?id=38756">bug 38756</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>FIXED
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [DebugInfo@O2][Dexter] Illegal value and unreachable lines seen when conditional stores merged"
href="https://bugs.llvm.org/show_bug.cgi?id=38756#c6">Comment # 6</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - [DebugInfo@O2][Dexter] Illegal value and unreachable lines seen when conditional stores merged"
href="https://bugs.llvm.org/show_bug.cgi?id=38756">bug 38756</a>
from <span class="vcard"><a class="email" href="mailto:orlando.hyams@sony.com" title="Orlando Cazalet-Hyams <orlando.hyams@sony.com>"> <span class="fn">Orlando Cazalet-Hyams</span></a>
</span></b>
<pre>I've taken another look at this.
At llvm git rev 99581fd4c8e there is only one backwards step left in this
example and I believe it is legitimate (or, that there is nothing we can do
about it at least).
Breakpoint 1, main () at repro.c:6
6 volatile int foo = 4;
1. (gdb) s
7 int bar = foo;
2. (gdb) s
10 if (bar & 1) {
3. (gdb) s
18 if (bar & 2) {
4. (gdb) s
10 if (bar & 1) {
5. (gdb) s
18 if (bar & 2) {
6. (gdb) s
26 return lolret;
The backwards step occurs between steps 3 and 4.
Looking at the generated MIR (-stop-after=finalize-isel) we can see the
backwards step (note: it is not present in the pre-isel IR):
dbg line | ...
18 | %lolret.1 = select i1 %tobool4, i32 %add9, i32 %add7
10 | TEST32rr %5, %5, implicit-def $eflags
0 | JCC_1 %bb.1, 4, implicit $eflags
0 | JMP_1 %bb.3
| ...
The TEST32rr comes from the IR:
dbg line | ...
10 |%and = and i32 %foo.0.foo.0., 1, !dbg !27 ; line 10
|; vvv --- This instruction --- vvv
10 |%tobool = icmp eq i32 %and, 0, !dbg !27 ; line 10
| ...
Which comes from the source expression `(bar & 1)`. According to the graph from
-view-dag-combine1-dags, the value from the setcc instruction which takes the
place of that IR instruction has 4 uses.
After the first SelectionDAG optimisation the dependencies are rejigged such
that there's only one use: the terminating branch of the first basic block.
The instruction is then moved down next to that terminating branch (presumably
during SelectionDAG scheduling phase).</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>