<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 --- - Unswitching of condition inside case statement of switch" href="https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D24221&d=AwMBaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=pF93YEPyB-J_PERP4DUZOJDzFVX5ZQ57vQk33wu0vio&m=MUeTsuLlt-HK49HHgZLveHFvSWnbEfrfCgWT-Cnnlag&s=HqK6jyJUXPQKkAZ0Lau6TH23WsIdi8GxXLdeJVsJAP8&e=">24221</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Unswitching of condition inside case statement of switch
</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>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>listmail@philipreames.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvmbugs@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Fair warning, this bug is really speculative. :)
I ran across an interesting snippet of IR copied below. This structure is
basically selecting between two particular destination blocks based on a
combined predicate on two input variables. What's interesting is that if
%local_2_ is 0, one of those destinations is always chosen, regardless of the
other input. This reminds me a lot of loop unswitch. We could consider
interchanging the branch and the switch provided the profiling data indicated
the non-default branches of the switch were dominant.
define void @test2(i16 %val1, i32 %local_2_) {
bci_84:
switch i16 %val1, label %bci_149 [
i16 45, label %merged
i16 43, label %merged
i16 58, label %merged
i16 95, label %merged
i16 46, label %merged
]
bci_149: ; preds = %merged, %bci_84
tail call void @foo()
ret void
bci_158: ; preds = %merged
tail call void @bar()
ret void
merged: ; preds = %bci_84, %bci_84,
%bci_84, %bci_84, %bci_84
%.old = icmp eq i32 %local_2_, 0
br i1 %.old, label %bci_149, label %bci_158
}
This would produce:
define void @test2(i16 %val1, i32 %local_2_) {
bci_84:
%.old = icmp eq i32 %local_2_, 0
br i1 %.old, label %bci_149, label %switch
switch:
switch i16 %val1, label %bci_149 [
i16 45, label %bci_158
i16 43, label %bci_158
i16 58, label %bci_158
i16 95, label %bci_158
i16 46, label %bci_158
]
bci_149: ; preds = %merged, %bci_84
tail call void @foo()
ret void
bci_158: ; preds = %merged
tail call void @bar()
ret void
}
Not sure how profitable this would be in general, but it avoids a switch
dispatch along the path where %local_2_ is zero. If that were the dominant
path, the switch could be placed entirely out of line.</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>