[llvm-bugs] [Bug 40091] New: SimplifyDemandedVectorElts' handling of undef

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Dec 18 11:26:20 PST 2018


            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: unassignedbugs at nondot.org
          Reporter: david.green at arm.com
                CC: llvm-bugs at lists.llvm.org, llvm-dev at 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) {
  %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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20181218/09620728/attachment.html>

More information about the llvm-bugs mailing list