aarch64 global isel backend miscompiles funnel shift with undef amount

[regehr]

here's one from our unit tests:

declare i32 @llvm.fshl.i32(i32, i32, i32) #0

define i32 @fshl_scalar_undef_shamt() {
  %1 = call i32 @llvm.fshl.i32(i32 1, i32 2, i32 undef)
  ret i32 %1
}

the global isel backend returns an arbitrary 32-bit value: https://gcc.godbolt.org/z/Yvbx9P7K4

but that's not OK. this is the set of permissible return values:

1
2
4
8
16
32
64
128
256
512
1024
2048
4096
8192
16384
32768
65536
131072
262144
524288
1048576
2097152
4194304
8388608
16777216
33554432
67108864
134217728
268435456
536870912
1073741824
2147483649

cc @aemerson @ornata @nunoplopes @ryan-berger @nbushehri @zhengyang92 @efriedma-quic

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

[regehr]

here are a couple more that fit the same pattern, probably more places where freeze is needed

https://gcc.godbolt.org/z/7zP4dKTGo

both of these are straight out of our unit test suite, no fuzzing is occurring

[ornata]

https://reviews.llvm.org/D135020 fixes the urem_undef_lhs case

[ornata]

abs: https://reviews.llvm.org/D135021

[ornata]

Funnel shifts: https://reviews.llvm.org/D135022

I just matched the SelectionDAG behaviour here, which for scalars replaces the shift with the first or second operand. I'm not sure if that's the correct behaviour (since I can't seem to find the code that actually handles this), but it's more correct than not emitting anything.

[regehr]

current status is that I'm seeing this issue on funnel shift (@ornata has a patch in flight) and then also srem: https://gcc.godbolt.org/z/Td4qEaz43

[aemerson]

Picking this back up, I think we need to address the concerns about the differences between scalar/vectors in https://reviews.llvm.org/D135022 and then implement fold for SREM as well.