<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 - InstCombine does not simplify a "get first bit" kind of pattern due to no longer folding trunc over select"
href="https://bugs.llvm.org/show_bug.cgi?id=44545">44545</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>InstCombine does not simplify a "get first bit" kind of pattern due to no longer folding trunc over select
</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>Windows NT
</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>Scalar Optimizations
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>bjorn.a.pettersson@ericsson.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org, spatel+llvm@rotateright.com
</td>
</tr></table>
<p>
<div>
<pre>Once upon-a-time, before this commit
commit e5bc4417913a3e606d572a5d661106612d3a99a7
Author: Sanjay Patel <<a href="mailto:spatel@rotateright.com">spatel@rotateright.com</a>>
Date: Thu May 31 00:16:58 2018 +0000
[InstCombine] don't change the size of a select if it would mismatch its
condition operands' sizes
Don't always:
cast (select (cmp x, y), z, C) --> select (cmp x, y), (cast z), C'
This is something that came up as far back as D26556, and I lost track of
it.
I suspect that this transform is part of the underlying problem that is
inspiring some of the recent proposals that seek to match larger patterns
that include a cast op. Even if that's not true, this transform causes
problems for codegen (particularly with vector types).
A transform to actively match the size of cmp and select operand sizes
should
follow. This patch just removes the harmful canonicalization in the other
direction.
Differential Revision: <a href="https://reviews.llvm.org/D47163">https://reviews.llvm.org/D47163</a>
llvm-svn: 333611
the IR below was simplified by instcombine as
%t0 = call i32 @llvm.cttz.i32(i32 %data, i1 true)
%iszero = icmp eq i32 %data, 0
%0 = trunc i32 %t0 to i16
%sub = select i1 %iszero, i16 -1, i16 %0
ret i16 %sub
but nowadays instcombine doesn't simplify it at all.
;------------------------------------------------------------
; RUN: opt < %s -S -instcombine | FileCheck %s
declare i32 @llvm.cttz.i32(i32, i1)
define i16 @foo(i32 %data) {
entry:
%t0 = call i32 @llvm.cttz.i32(i32 %data, i1 true)
%t1 = add nuw nsw i32 %t0, 1
%iszero = icmp eq i32 %data, 0
%ffs = select i1 %iszero, i32 0, i32 %t1
%cast = trunc i32 %ffs to i16
%sub = add nsw i16 %cast, -1
ret i16 %sub
}
;------------------------------------------------------------
The patterns origins from a C function that count trailing zero bits in %data,
but returns -1 if the input is zero.
If I understand it correctly instcombine started to be more careful about
folding casts over select in case the condition origins from a cmp with same
bit width as the select operands. The idea was that lots of other combines
could trigger if not doing the rewrite.
No idea how to tackle this. In the example above it would have been good to do
the folding. Maybe there are lots of situations like this, when we'd benefit
from doing the fold.</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>