Update llvm to 22.1.8

[Megamouse]

• Updates LLVM to 22.1.8

closes #19039

[cipherxof]

I'm getting slightly worse performance in LLVM 20 compared to 19, which already had worse AVX512 performance than LLVM 17 (#16733). Tested on a 8945HS.

LLVM 19:

LLVM 20:

[crashGG]

But there is no
https://github.com/RPCS3/llvm-mirror/releases/download/custom-build-win-20.1.2/llvmlibs_mt.7z
So can't build the win64 version to test.
Can anyone help?

[Megamouse]

There won't be a prebuilt until we decide to merge this.

[Darkhost1999]

Rpcs3_default.props doesn't change from llvm 20.1.7 to 20.1.8.
Are minor performance regressions a stopper for PRs like these?
I thought the goal is to test stability. Performance is allowed to fluctuate a little bit, especially with numbers as high as 120+

[kd-11]

Rpcs3_default.props doesn't change from llvm 20.1.7 to 20.1.8. Are minor performance regressions a stopper for PRs like these? I thought the goal is to test stability. Performance is allowed to fluctuate a little bit, especially with numbers as high as 120+

It's incremental just like optimizations are. We already had another drop coming from 17 to 19 then 19 to 20. Obviously something is wrong and needs to be identified. Otherwise by the time we reach llvm30 we'll have lost a lot of performance without making any significant code changes in our own code.

When no code changes product side have been made, regressions are a lot more concerning than when our own code is being modified because then we know the pros vs cons. We never commit our own code changes if they do nothing but hurt performance - the amount of experimental code that gets thrown out could probably create another (horrible) PS3 emulator.

In this case we have a change that provides zero pros, just cons, making it not worth the effort. If the cause is identified, we can proceed just to be up to date with the latest version of llvm. Something I am curious about is whether the problem goes away if we use the clang64 windows binaries?

[cipherxof]

Someone had mentioned improved performance on discord, so I figured I would re-check. On my end (/w AVX512), performance still seems to be slightly lower with LLVM 22 vs 19. Although this is a MSVC vs Clang comparison as the CI failed to build for MSVC for this PR.

Master (where this PR is rebased):

PR:

The difference is fairly small, so if non-avx512 machines see a decent speedup then it may be worth merging anyways.

[Darkhost1999]

What's the best llvmcpu configuration value to test without avx512 support? Is there a reference file or link to verify the spelling of the enumerator and what options are available inside LLVM?

[cipherxof]

What's the best llvmcpu configuration value to test without avx512 support? Is there a reference file or link to verify the spelling of the enumerator and what options are available inside LLVM?

For my machine it would likely be alderlake. I'll test without avx512 later and post the results.

[AniLeo]

I think it's time we go ahead and merge this, since we're lagging quite a bit on LLVM versions, and the newer ones have better arm64 support as discussed internally

[Whatcookie]

Codegen should be better on newer llvm versions for arm64 , but need confirmation that comparability doesn't regress

[schm1dtmac]

Also needs a version bump in the macOS scripts, slightly complicated by the fact that Homebrew doesn’t have a version tag for 22 yet (as it’s the latest stable version). I’ll see what can be done there though. Shouldn't be an issue, llvm stable has an alternate name of llvm@22 on brew.

[AniLeo]

Unfortunately, all llvm22 versions have broken codegen

Latest working version that can be used is LLVM 21.1.8

I tried 22.1.0, 22.1.6 and 22.1.8 and they're all broken, the easiest repro is to boot RDR and see vertex explosion on the title screen 3D preview

Can't test LLVM release/23.x because our code is not compatible with the new API changes

[RipleyTom]

in rpcs3/Emu/CMakeLists.txt:

if(USE_ASAN)
    set_source_files_properties(../../Utilities/Thread.cpp PROPERTIES COMPILE_DEFINITIONS USE_ASAN)
endif()

...

# GCC overemits weak type information when using LTO
# This causes an issue with LLVM 22 which is build without RTTI
# Issue is specifically related to vfs::ProxyFileSystem
if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
    set_source_files_properties(
        Cell/PPUThread.cpp
        Cell/SPULLVMRecompiler.cpp
        PROPERTIES COMPILE_OPTIONS -fno-lto
    )
endif()

...

if(NOT USE_SYSTEM_OPENAL)
    target_compile_definitions(rpcs3_emu PUBLIC AL_LIBTYPE_STATIC)
endif()