Update LLVM to 18.1.8

[Megamouse]

closes #16032

[digant73]

As also reported in #16032, with MSVC compiling to DEBUG mode, after successfully compiling glslang and llvm I then got the following error compiling RPCS3:

Severity	Code	Description	Project	File	Line	Suppression State	Details
Error	LNK2038	mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in dualsense_pad_handler.obj	rpcs3	E:\console\git\rpcs3_megamouse\rpcs3\LLVMAnalysis.lib(ImportedFunctionsInliningStatistics.cpp.obj)	1		

while with the current llvm 16.0.1 it is possible to compile RPCS3 in DEBUG mode (glslang lib, llvn lib and RPCS3 bin)

[Darkhost1999]

Thanks to the changes in vcxproj that I wasn't aware of. I managed to compile RPCS3 with LLVM 19.1.7. Only had to work around unresolved linker error with llvmsupport.lib by adding ntdll.lib to the list of additional dependencies.
I believe llvmsupport.lib is supposed to look for ntdll itself and not sure if that may need to be reported to llvm prior to the next version bump we perform. Additionally, I don't know if it's desired to support the most recent release tag of LLVM now vs later.

[Megamouse]

Idk what issues you're talking about.
I'm just bumping the version to the one that's already used in Linux to get parity

[digant73]

Idk what issues you're talking about.

Is that a reply to @Darkhost1999 or to me?

[Megamouse]

@digant73 debug is fixed

[digant73]

@digant73 debug is fixed

thanks for the fix.

A runtime error present also on current and old RPCS3 releases compiled in DEBUG mode is triggered when starting a game with PPU Decoder setting on CPU tab set to Recompiler (LLVM).
Precisely, when Applying PPU code... is displayed on the game window then RPCS3 is aborted (a dialog box reporting the abort is displayed).
That abort message is due to JIT module not initialized. In particular the abort dialog is triggered by the execution of line code:

jit->fin();

at line 5511 in PPUThread.cpp.
Below the block of code with the above line of code:

const bool is_first = !jit_mod.init;

if (is_first)
{
	for (auto& jit : jits)
	{
		jit->fin();                      // <--- line 5511 in PPUThread.cpp triggering the abort message
	}
} 

It should be great if that issue (abort due to JIT module not initialized) happening only in DEBUG mode could also be fixed, maybe on a separate PR.
Probably it is due to a missing/wrong compile option on LLVM 3rdparty than a bug in RPCS3.
Maybe the expert on that topic is @elad.
If it could be fixed, I could finally run games in DEBUG mode from VS for some troubleshooting.

[Darkhost1999]

I get the same in every call stack on every executable I boot. Just tried not 1 hour ago as well.

[Megamouse]

Works fine for me on Vulkan. Never had that issue

[digant73]

@Megamouse because you used RPCS3 compiled in RELEASE mode

[elad335]

@digant73 debug is fixed

thanks for the fix.

A runtime error present also on current and old RPCS3 releases compiled in DEBUG mode is triggered when starting a game with PPU Decoder setting on CPU tab set to Recompiler (LLVM). Precisely, when Applying PPU code... is displayed on the game window then RPCS3 is aborted (a dialog box reporting the abort is displayed). That abort message is due to JIT module not initialized. In particular the abort dialog is triggered by the execution of line code:

jit->fin();

at line 5511 in PPUThread.cpp. Below the block of code with the above line of code:

const bool is_first = !jit_mod.init;

if (is_first)
{
	for (auto& jit : jits)
	{
		jit->fin();                      // <--- line 5511 in PPUThread.cpp triggering the abort message
	}
} 

It should be great if that issue (abort due to JIT module not initialized) happening only in DEBUG mode could also be fixed, maybe on a separate PR. Probably it is due to a missing/wrong compile option on LLVM 3rdparty than a bug in RPCS3. Maybe the expert on that topic is @elad. If it could be fixed, I could finally run games in DEBUG mode from VS for some troubleshooting.

Don't merge it if it is incompatible with #16537

[digant73]

@elad335 the bug I mentioned (in DEBUG mode) is present also in current LLVM 16.0.1. For some reasons the JIT module seems not initialized if using the LLVM libs compiled in DEBUG mode. You can verify it also in #16537 compiling (with VS or even cmake) glslang, llvm and RPCS3 in DEBUG mode. Everything is ok in RELEASE mode (also with llvm 18.1.8)

[Megamouse]

Of course I'm using debug config. That's what we've been talking about.

[digant73]

Of course I'm using debug config. That's what we've been talking about.

I have a Ryzen 7800x3d. I thought that maybe llvm was providing full functionality in RELEASE mode only. But if you say it is working also in DEBUG mode there is possibly something to investigate.
@Darkhost1999 could you please confirm the issue running rpcs3d.exe (if you are on Windows as me)?

Below a screenshot of the issue on R3, but it is the same on all games with PPU Decoder set to Recompiler (LLVM):

[Darkhost1999]

I have a Ryzen 7 7700x but this issue wasn't caused by this PR or that.
This has been around since debug builds were fixed compiling in the first place after years of not being able to compile at all if it was around before debug mode wasn't compiling to be able to test.
I am discussing running the executable rpcs3d.exe through visual studio clicking the green play button after setting RPCS3 as the start up solution.
I also admit I'm not very familiar with using a debugger and only try to see if I can learn something.
But every time I'm about 50% of the way through generating or loading llvm cache I get the JIT message among other messages in my callstack while abort was called.
Idk know Vulkan = PPU thread that was just an interesting thing to read. But I also don't think filling up this thread with offtopic posts is the answer.
We discovered Megamouse can't replicate the issue so it's up to someone experiencing the problem to try and solve the problem. Maybe even create an issue ticket.

[digant73]

But I also don't think filling up this thread with offtopic posts is the answer. We discovered Megamouse can't replicate the issue so it's up to someone experiencing the problem to try and solve the problem. Maybe even create an issue ticket.

Yes, I agree