fuzzgen: Generate Tail Calls #6641
Conversation
github-actions
bot
added
cranelift
Subscribe to Label Action
This issue or pull request has been labeled: "cranelift", "cranelift:area:aarch64", "cranelift:area:machinst", "cranelift:area:x64", "isle"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
|
Nice! The last commit LGTM, thanks for putting this up. Going to look into the issues you found now. |
afonso360
force-pushed
the
fuzzgen-tail-calls
branch
from
8b8c45b to
f715416
Compare
github-actions
bot
added
the
fuzzing
Subscribe to Label Actioncc @fitzgen
This issue or pull request has been labeled: "fuzzing"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
afonso360
force-pushed
the
fuzzgen-tail-calls
branch
from
f715416 to
f87252d
Compare
|
Fuzzed for around 2 hours with fuzzgen and it all seems stable! 🥳 |
|
@fitzgen would you be able to look into this again? It should be ready now. I've just rebased the latest commit onto the main branch. |
| let addr_ty = args[0]; | ||
| let addr = builder.ins().func_addr(addr_ty, func_ref); | ||
| builder.ins().call_indirect(sig_ref, addr, &actuals) | ||
| let addr_ty = I64; |
There was a problem hiding this comment.
Can we maybe factor this out to a helper that checks cfg!(target_pointer_width = "64") and then has an else that panics with a helpful message? Just to future proof this a little bit.
There was a problem hiding this comment.
Turns out we can already query the ISA's pointer type directly, so I've done just that.
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
👋 Hey,
This PR is a follow up to #6635 and it allows fuzzgen to generate
return_callandreturn_indirect_callinstructions. These are modeled as any other control flow instruction however they have a bunch of restrictions before we are actually able to insert them.As with the other control flow instructions, we try to include as much info as possible in the CFG before inserting it. It doesn't seem as relevant with tail calls as it is with blocks, but I figured it is still worth it. (The alternative would be to pick the tail call target at instruction insertion time, but I think that would actually make this slightly more complicated)
I'm opening this as a draft since it has found some issues and I can't run it for too long before it crashes, and I'm not entirely sure it's generating correct code under all inputs. Just leaving this open if anyone wants to test with it (@fitzgen 👀 ).