mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-10-19 11:02:59 +02:00
4d8551cc64
As described on PR40091, we have several places where zext (and zext_vector_inreg) fold an undef input into an undef output. For zero extensions this is incorrect as the output should guarantee to least have the new upper bits set to zero. SimplifyDemandedVectorElts is the worst offender (and its the most likely to cause new undefs to appear) but DAGCombiner's tryToFoldExtendOfConstant has a similar issue. Thanks to @dmgreen for catching this. Differential Revision: https://reviews.llvm.org/D55883 llvm-svn: 349625
23 lines
777 B
LLVM
23 lines
777 B
LLVM
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
; RUN: llc < %s -mtriple=aarch64-arm-none-eabi | FileCheck %s
|
|
|
|
define i64 @test(i64 %aa) {
|
|
; CHECK-LABEL: test:
|
|
; CHECK: // %bb.0: // %entry
|
|
; CHECK-NEXT: movi v0.8b, #137
|
|
; CHECK-NEXT: fmov x0, d0
|
|
; CHECK-NEXT: ret
|
|
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
|
|
}
|