Sam Schweigel

The 32 bit arm `CallSystemFunctionNative` won't work for some aarch64 systems (like Apple processors),. Angelscript since 2.36.0 supports aarch64-linux, so in the interest of having more games to test on...

> It looks like this is required after [JuliaLang/julia#58187](https://github.com/JuliaLang/julia/pull/58187)? Issue autocomplete strikes again. That's the one I intended to link.

It's a little different from the GPUCompiler approach, since it makes no attempt to predict if a CodeInstance will ultimately emit the same code. Instead, we emit LLVM as normal...

Reverted two commits that were an attempt at getting better cache hit rates with the simplest possible change, in favour of doing a link-time rename step.

I said would I write my thoughts here after triage then got sidetracked hunting down libuv bugs. Woops. I agree with @oscardssmith that fixing `cp` on large files is important...

~~WIP -- I grabbed e977d6f499a from #60326 to see if this change broke something on x86_64-darwin or if it is the known problem.~~ Rebased on top of master now that...

No, this PR only changes code generation.

This new commit fixes some horrible code generation in `emit_pkg_plt_thunk` by just emitting inline assembly, using PLT thunks stolen from LLD. This will be less hacky when it happens after...

I'm guessing the PR in question is #44575? Some of the concerns have been addressed by #55106 and #56179, at least, so it would be easier to try this again...

I believe this was enabled at one point for ahead-of-time compilation but disabled because of miscompiles? I should probably report/fix the easy ones upstream... https://github.com/JuliaLang/julia/pull/54140#issuecomment-2855794363 The atomic Float16 miscompile still...