llvm/pr20678.ll at 1d1dc060d7e8f5684c7c424a6990be1a3a38194b - llvm - Gitea: Git with a cup of tea

RPCSX/llvm

mirror of https://github.com/RPCSX/llvm.git synced 2024-11-24 20:29:53 +00:00

David Majnemer c454f3e111 [ConstantFolding, ValueTracking] Fold constants involving bitcasts of ConstantVector

We assumed that ConstantVectors would be rather uninteresting from the
perspective of analysis.  However, this is not the case due to a quirk
of how LLVM handles vectors of i1.  Vectors of i1 are not
ConstantDataVectors like vectors of i8, i16, i32 or i64 because i1's
SizeInBits differs from it's StoreSizeInBytes.  This leads to it being
categorized as a ConstantVector instead of a ConstantDataVector.

Instead, treat ConstantVector more uniformly.

This fixes PR27591.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268479 91177308-0d34-0410-b5e6-96231b3b80d8

2016-05-04 06:13:33 +00:00

9 lines

343 B

LLVM

Raw Blame History

 ; RUN: opt -S -instcombine < %s | FileCheck %s
 define i1 @test1() {
 entry:
   ret i1 icmp ne (i16 bitcast (<16 x i1> <i1 true, i1 true, i1 true, i1 true, i1 true, i1 true, i1 true, i1 true, i1 false, i1 false, i1 false, i1 false, i1 false, i1 false, i1 false, i1 false> to i16), i16 0)
 }
 ; CHECK-LABEL: define i1 @test1(
 ; CHECK:  ret i1 true