[llvm-bugs] [Bug 44545] New: InstCombine does not simplify a "get first bit" kind of pattern due to no longer folding trunc over select

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=44545

            Bug ID: 44545
           Summary: InstCombine does not simplify a "get first bit" kind
                    of pattern due to no longer folding trunc over select
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: bjorn.a.pettersson at ericsson.com
                CC: llvm-bugs at lists.llvm.org, spatel+llvm at rotateright.com

Once upon-a-time, before this commit

 commit e5bc4417913a3e606d572a5d661106612d3a99a7
 Author: Sanjay Patel <spatel at rotateright.com>
 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: https://reviews.llvm.org/D47163

     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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200114/9cf50db8/attachment.html>