<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 - Regression: br_cc not formed after r325892"
href="https://bugs.llvm.org/show_bug.cgi?id=36519">36519</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Regression: br_cc not formed after r325892
</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>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>qcolombet@apple.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=19963" name="attach_19963" title="Reproducer">attachment 19963</a> <a href="attachment.cgi?id=19963&action=edit" title="Reproducer">[details]</a></span>
Reproducer
Author: deadalnix
Date: Fri Feb 23 03:50:42 2018
New Revision: 325892
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=325892&view=rev">http://llvm.org/viewvc/llvm-project?rev=325892&view=rev</a>
Log:
[DAGCOmbine] Ensure that (brcond (setcc ...)) is handled in a canonical manner.
Summary:
There are transformation that change setcc into other constructs, and transform
that try to reconstruct a setcc from the brcond condition. Depending on what
order these transform are done, the end result differs.
Most of the time, it is preferable to get a setcc as a brcond argument (and
this is why brcond try to recreate the setcc in the first place) so we ensure
this is done every time by also doing it at the setcc level when the only user
is a brcond.
I am seeing cases where this change has actually the opposite effect than was
what intended, if I understood correctly.
In particular, I am seeing a case where we used to generate brcond(setcc(and))
from brcond(xor(and)), but now we end up with brcond(or(xor)). Thus, we failed
to produce br_cc.
Attached a reproducer:
llc -mtriple powerpc-- reduced.ll -o - -debug-only=isel
You’ll see in the debug output those diffs:
Optimized legalized selection DAG: %bb.3 't1_false1.split:false1.split'
SelectionDAG has 16 nodes:
t0: ch = EntryToken
- t8: i1,ch = CopyFromReg t0, Register:i1 %3
+ t8: i1,ch = CopyFromReg t0, Register:i1 %3
+ t16: i1 = xor t8, Constant:i1<-1>
t2: f32,ch = CopyFromReg t0, Register:f32 %0
t4: f32,ch = CopyFromReg t0, Register:f32 %1
- t6: i1 = setcc t2, t4, setolt:ch
- t9: i1 = and t8, t6
- t18: ch = br_cc t0, setne:ch, t9, Constant:i1<-1>,
BasicBlock:ch<true2.exitStub 0x7fbf0885d538>
- t15: ch = br t18, BasicBlock:ch<false2.exitStub 0x7fbf0885d5f8>
+ t21: i1 = setcc t2, t4, setuge:ch
+ t18: i1 = or t16, t21
+ t19: ch = brcond t0, t18, BasicBlock:ch<true2.exitStub 0x7fbf78053138> ###
<— we don’t get a br_cc anymore
+ t15: ch = br t19, BasicBlock:ch<false2.exitStub 0x7fbf780531f8></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>