https://bugs.llvm.org/show_bug.cgi?id=40091
Bug ID: 40091
Summary: SimplifyDemandedVectorElts' handling of undef
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: david.gr...@arm.com
CC: llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk
;target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
;target triple = "aarch64-arm-none-eabi"
define i64 @test(i64 %aa) {
entry:
%a = bitcast i64 %aa to <1 x i64>
%k = icmp sgt <1 x i64> %a, zeroinitializer
%l = zext <1 x i1> %k to <1 x i64>
%o = and <1 x i64> %l, %a
%p = xor <1 x i64> %l, <i64 -1>
%q = and <1 x i64> %p, <i64 81985529216486895>
%r = or <1 x i64> %q, %o
%s = bitcast <1 x i64> %r to <8 x i8>
%t = shufflevector <8 x i8> %s, <8 x i8> %s, <8 x i32> <i32 3, i32 3, i32 3,
i32 3, i32 3, i32 3, i32 3, i32 3>
%u = bitcast <8 x i8> %t to i64
ret i64 %u
}
I would expect this to always return 0x8989898989898989 (the third element of
that big constant in there), but currently returns 0xffffffffffffffff. It seems
that the icmp is folded to undef (perhaps because it is not needed by demand
bits), which then gets folded through into pretty much everything else (even
through the zext). I am under the impression that undef should be bitwise (not
vector-lane-wise), but I may be wrong there.
Bisects back to r349264, which adds OR handling to SimplifyDemandedVectorElts
(but it looks like a bit of a knock-on effect).
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
