`datetime` tests fail in release mode since 1.73 on powerpc64le

[cuviper]

The datetime tests have regressed on Fedora ppc64le since upgrading to Rust 1.73.0, and I can also reproduce this on rustup toolchains.
https://koschei.fedoraproject.org/build/16447830

I expected to see this happen: all tests pass

Instead, this happened: it passes in debug mode, but fails multiple tests in --release. For example:

$ cargo test --test instant_to_datetime --release -- the_end_of_time
[...]
     Running tests/instant_to_datetime.rs (target/release/deps/instant_to_datetime-dc863ddaa1b40632)

running 1 test
test the_end_of_time ... FAILED

failures:

---- the_end_of_time stdout ----
thread 'the_end_of_time' panicked at tests/instant_to_datetime.rs:80:5:
assertion `left == right` failed
  left: -1
 right: 7

Version it worked on

It most recently worked on: 1.72.1

Version with regression

rustc --version --verbose:

rustc 1.73.0 (cc66ad468 2023-10-03)
binary: rustc
commit-hash: cc66ad468955717ab92600c770da8c1601a4ff33
commit-date: 2023-10-03
host: powerpc64le-unknown-linux-gnu
release: 1.73.0
LLVM version: 17.0.2

It's no better on rustc 1.74.0-beta.1 (b5c050feb 2023-10-03) or rustc 1.75.0-nightly (bf9a1c8a1 2023-10-08).

As noted above, it also fails on Fedora rawhide's Rust 1.73.0 with LLVM 17. However, it passes on Fedora 38 with Rust 1.73.0 and LLVM 16, so it definitely seems like a codegen regression in 17.

@rustbot modify labels: +A-LLVM +T-compiler +regression-from-stable-to-stable -regression-untriaged

[nikic]

Doesn't happen when calling at_ms() with a zero argument instead, so probably something gets miscompiled when at_ms() is inlined into at() and specialized for 0.

[nikic]

opt-bisect points towards a backend issue:

BISECT: running pass (19571) Two-Address instruction pass on function (_ZN8datetime3cal8datetime13LocalDateTime2at17h068a3ad6fbe82580E)
BISECT: NOT running pass (19572) Machine Instruction Scheduler on function (_ZN8datetime3cal8datetime13LocalDateTime2at17h068a3ad6fbe82580E)

IR for the function looks like this: https://gist.github.com/nikic/6752e057cf4f933e592277e4a9211d6a

[nikic]

The issue is already introduced during the SDAG layer by a custom combine: https://github.com/llvm/llvm-project/blob/12a4757b0fa25baac853498671a34e2f34f92b80/llvm/lib/Target/PowerPC/PPCISelLowering.cpp#L15570-L15591

This is interchanging and(any_ext(x),c) to any_ext(and(x,c)), which is obviously incorrect and should be zext(and(x,c)) instead.