ppsspp

I have seen a few cases in the last couple of years of FOSS bug reports where the author has used PVS-Studio or similar static code analysis tools, and makes a big deal about perceived issues, without really understanding what's going on. These are not LLM at all, but its the same general issue in that it takes 10 second to generate a report but takes days or weeks to comb through all the noise for the FOSS maintainers. Most recently, this one https://github.com/hrydgard/ppsspp/issues/19515

It was a bit more complicated than that: the issue was that one of the early big.LITTLE designs (Samsung's Exynos 8890) had different cacheline sizes on the big and little cores. glibc's `__clear_cache` would cache the cacheline size on first call, so if the program was started on a big core then migrated onto a little core it would only flush every other cacheline. Which was an issue for any program needing to explicitely clear the caches, like most any JIT. And the mitigation was not to "change its allocation", it was to bypass libgcc and handroll cache clearing: https://github.com/mono/mono/pull/3549 Source: https://www.mono-project.com/news/2016/09/12/arm64-icache/ This issue didn't only affect Mono e.g. dolphin (https://github.com/dolphin-emu/dolphin/pull/4204) and ppsspp (https://github.com/hrydgard/ppsspp/pull/8965) had been hittin

Are you sure? I admittedly can't find a definitive source on this now, so perhaps the restriction is more nuanced than I realized. What I do know is: if you try to use more intensive emulators like PPSSPP on a non-Jailbroken iOS device (via a developer account, enterprise cert, or similar), you will not get acceptable performance, because the emulator is forced to fall back into an interpreter mode. Even on Jailbroken devices, the hacks required to make JIT work cause weird issues: https://github.com/hrydgard/ppsspp/issues/9186