PowerPC regressions introduce by 3469db82b5c821c94b58c0b81f03bbef51efa30b

[tstellar]

I'm seeing a test failure in our Fedora builds of the highway package on ppc64le, and I've bisected the failures down to 3469db8 (#108430)

How to reproduce in the fedora:rawhide container for ppc64le:

$ curl -O -L https://download.copr.fedorainfracloud.org/results/tstellar/clang-fedora-centos-testing/fedora-rawhide-ppc64le/09017423-highway/highway-1.2.0-5.fc43.src.rpm
$ dnf builddep highway-1.2.0-5.fc43.src.rpm
$ dnf install rpm-build
$ rpmbuild -D "%_distro_extra_ldflags -fuse-ld=lld" -rb highway-1.2.0-5.fc43.src.rpm

cc @alexey-bataev

[alexey-bataev]

No idea what to do with this repro

[tstellar]

@alexey-bataev I can try to reduce it further.

[alexey-bataev]

This will help, thanks!

[tstellar]

@alexey-bataev The bug is only reproducible with LTO, so here are the outputs from lld -save-temps:

• bit_pack_test.cc.o.3.import.ll.txt is the LLVM IR before optimization.
• bit_pack_test.cc.o.4.opt.good.ll.txt is the output after optimization prior to 3469db8
• bit_pack_test.cc.o.4.opt.bad.ll.txt is the output after optimization with 3469db8.

It looks like block 908 in @_ZN3hwy6N_PPC913TestAllPack16Ev is where the good and bad outputs begin to diverge. Let me know if this is helpful or if you have tips for reducing further.

[alexey-bataev]

Do I understand correctly that it is in release 20? If so, can you try trunk? I don't see anything wrong in the provided code, looks correct. Maybe the codegen issue?

[tstellar]

@alexey-bataev I can reproduce on trunk too. I'll take a look at the codegen.