Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aarch64/llvm: Improve compatibility #15962

Merged
merged 4 commits into from
Aug 18, 2024
Merged

aarch64/llvm: Improve compatibility #15962

merged 4 commits into from
Aug 18, 2024

Conversation

kd-11
Copy link
Contributor

@kd-11 kd-11 commented Aug 18, 2024

The previous experiment (lowering all tail calls to branch) worked really well, but at IR level we lack the flexibility to solve some problems. A common one is that we would clobber our own data due to cyclic assignments on very large functions with high register pressure. For example

start:
  ... code
  mov x23, x20; // x20 now saved in x23. In practice this would be a computation
  ... our injected branch
  mov x23, x14;  // Final x23 value was in x14, so we overwtite
  mov x20, x23; // Attempt to restore x20 now loads x14 into it
  br target;         // Target called with invalid arg

After several variations attempted, I came to the conclusion that this approach will never work at IR level. LLVM can be "dumb" sometimes even when register clobbering information is communicated properly.
A simpler approach is to let the link register overwrite happen and simply reload it on return. This was not an option previously due to the way the stack behaved in earlier iterations, but the shape of the current calls ensures this is not a problem:

  1. GHC calls will never return to other GHC functions.
  2. Leaf functions will also not return, aborting to gateway each time. This makes all paths loop back to the start.
  3. Calls to C++ functions will preserve the frame on the callee side, so we don't need to worry too much about corruption on the return path at the point of reception. This is only guaranteed once.
  4. An extra assumption we can make is that static tail calls to GHC functions will never return. A trap is inserted to verify this and it is only hit when we emit incorrect code.

A side effect of this is that the dummy movs disappeared and we don't need to post-process the machine code for to fix them up anymore. This makes the codegen much smaller and there is a small perf boost to go along with that.

@kd-11 kd-11 merged commit fbcd8e3 into RPCS3:master Aug 18, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants