<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 - Poor codegen for targets with no native shifts"
href="https://bugs.llvm.org/show_bug.cgi?id=43542">43542</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Poor codegen for targets with no native shifts
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</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>Common Code Generator Code
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>joan.lluch@icloud.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>This is a recurrent problem that I have found while developing backends for
simple 8 bit or 16 bit targets. The problem is rather generic and related with
the fact that LLVM considers shifts as cheap operations, without giving the
targets the opportunity to tell the contrary. This causes poor codegen for
targets with expensive shifts, such as the majority of 8 bit and 16 bit
processors, including trunk targets (MSP430, AVR), and new targets in
development.
I am showing just one instance of this happening for the MSP430 target.
However, I strongly suggest that this problem is considered as a LLVM wide bug
and as such a generic solution is proposed. In this case the offender is found
in DAGCombiner::SimplifySelectCC
Consider the following C code:
int select_and( int a, int b)
{
unsigned int r = 0;
if (a & 2)
r = b;
return r;
}
This is compiled into :
; Function Attrs: norecurse nounwind readnone
define dso_local i16 @select_and(i16 %a, i16 %b) local_unnamed_addr #0 {
entry:
%and = and i16 %a, 2
%tobool = icmp eq i16 %and, 0
%spec.select = select i1 %tobool, i16 0, i16 %b
ret i16 %spec.select
}
Which is then turned into this for the MSP430 target
.text
.file "main.c"
.globl select_and
.p2align 1
.type select_and,@function
select_and:
mov.b r12, r12
swpb r12
add r12, r12
add r12, r12
add r12, r12
add r12, r12
add r12, r12
add r12, r12
swpb r12
sxt r12
rra r12
rra r12
rra r12
rra r12
rra r12
rra r12
rra r12
and r13, r12
ret
.Lfunc_end0:
.size select_and, .Lfunc_end0-select_and
This is suboptimal and ultimatelly caused by the following fold:
(select_cc seteq (and x, y), 0, 0, A) -> (and (shr (shl x)) A)
that happens in DAGCombiner::SimplifySelectCC
As said this is only ONE case where selects or other instructions are replaced
by expensive shifts, ultimately creating long and slow code on targets with no
native support of multiple shifts.
John</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>