afonso360 opened PR #8868 from afonso360:riscv-inst-size-2
to bytecodealliance:main
:
:wave: Hey,
This PR fixes #8866. It is also a follow up to #8850, in that PR I forgot to add some of the fields into the frame layout which end up having a codegen effect for the return call instruction.
I've updated these fields with a somewhat real but worse case scenario. This ends up generating a lot of instructions though.
afonso360 requested cfallin for a review on PR #8868.
afonso360 requested wasmtime-compiler-reviewers for a review on PR #8868.
cfallin submitted PR review:
LGTM, thanks!
I'm idly wondering whether we need a better mechanism for island deadlines with such a large worst-case: number of instructions * max instruction size becomes a very very loose upper bound with such high variance in pseudoinst size. I don't think there's a good way to split return-call sequences into multiple pseudoinsts though. Definitely don't want to go back to a two-pass "compute the size first" mechanism, that will pessimize the common case. Hmm...
alexcrichton commented on PR #8868:
The test failures here show something that I was a little worried about in that the jump distance of riscv64 is pretty limited so with the very large max worst case times the number of instructions it means that islands are getting emitted much more frequently, even for relatively small functions.
IIRC though I think it's an option to, in the implementation of lowering of
ReturnCall
, that island checks are explicitly inserted? That way theReturnCall
instruction itself could calculate the size it needs, perform custom island-checking logic, and otherwise the maximum size of an instruction could go back to being significantly smaller (e.g. 5 or so instructions)
cfallin commented on PR #8868:
Yes, there is a mechanism for this, and we use it for
br_table
s in aarch64 here; that's probably the better option to replicate for return-call pseudoinsts.
afonso360 updated PR #8868.
afonso360 commented on PR #8868:
Yeah, that's a much better solution! The calculation for the exact number of instructions was fairly complex so I emitted it into a fake buffer and used that. If that is too much overhead, maybe we can find some conservative limit for estimating the isle distance?
Also, the new instruction size limit is so low that I'm worried we are going to find some combination of an existing instruction that is larger than that. I'm going to run the fuzzer for a bit, lets see if it finds a larger instruction.
cfallin submitted PR review:
New approach LGTM, thanks! Good idea to check the reduced limit.
afonso360 updated PR #8868.
Maybe rename this PR?
Last updated: Nov 22 2024 at 16:03 UTC