shift/zext-related miscompile by aarch64 backend

[regehr]

here's a function:

define i64 @f(i64) {
  %2 = lshr i64 %0, 32
  %3 = shl i64 %2, 16
  %4 = trunc i64 %3 to i32
  %5 = ashr exact i32 %4, 16
  %6 = zext i32 %5 to i64
  ret i64 %6
}

alive2 and the x86-64 backend agree that f(0x0000800000000000) -> 0x00000000ffff8000

using this reasoning:

i64 %2 = #x0000000000008000 (32768)
i64 %3 = #x0000000080000000 (2147483648)
i32 %4 = #x80000000 (2147483648, -2147483648)
i32 %5 = #xffff8000 (4294934528, -32768)
i64 %6 = #x00000000ffff8000 (4294934528)

but separately, it's easy to see that since the last instruction is a zext, the high part of the result must contain zeroes (unless there's been a poison-related problem, but it doesn't look like there has been).

here's what we get from the aarch64 backend in llvm 14 and also top-of-tree:

Johns-MacBook-Pro:~ regehr$ ~/llvm-project/for-alive/bin/llc foo.ll -o -
	.section	__TEXT,__text,regular,pure_instructions
	.build_version macos, 12, 0
	.globl	_f                              ; -- Begin function f
	.p2align	2
_f:                                     ; @f
	.cfi_startproc
; %bb.0:
	sbfx	x0, x0, #32, #16
	ret
	.cfi_endproc
                                        ; -- End function
.subsections_via_symbols
Johns-MacBook-Pro:~ regehr$ 

this ends up with a result where all the high bits are set:

Johns-MacBook-Pro:~ regehr$ cat foo.c
#include <stdio.h>

unsigned long f(unsigned long);

int main(void) {
  printf("%lx\n", f(0x0000800000000000ULL));
}
Johns-MacBook-Pro:~ regehr$ ~/llvm-project/for-alive/bin/llc foo.ll && clang foo.c foo.s && ./a.out
ffffffffffff8000
Johns-MacBook-Pro:~ regehr$ 

cc @ornata @nunoplopes @ryan-berger @nbushehri @zhengyang92 @aqjune @Hatsunespica

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

[davemgreen]

This looks like a conflict between the selection code in AArch64DAGToDAGISel::tryBitfieldExtractOp and isDef32 used in the zext patterns, meaning it misses a mov w0, w0 that is needed to zero-extend the higher bits.