abrown opened PR #1517 from run-clif
to master
:
This resolves the work started in https://github.com/bytecodealliance/cranelift/pull/1231 and https://github.com/bytecodealliance/wasmtime/pull/1436. Cranelift filetests currently have the ability to run CLIF functions with a signature like
() -> b*
and check that the result is true under thetest run
directive. This PR adds the ability to call functions with arbitrary arguments and non-boolean returns and either print the result or check against a list of expected results:
run
commands look like; run: %add(2, 2) == 4
or; run: %add(2, 2) != 5
and verify that the executed CLIF function returns the expected value; print: %add(2, 2)
and print the result of the function to stdoutTo make this work, this PR compiles a single Cranelift
Function
into aCompiledFunction
using aSingleFunctionCompiler
. Because we will not know the signature of the function until runtime, we use aTrampoline
to place the values in the appropriate location for the calling convention; this should look a lot like what @alexcrichton is doing withVMTrampoline
in wasmtime (see https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/api/src/func.rs#L510-L526, https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/jit/src/compiler.rs#L260). To avoid re-compilingTrampoline
s for the same function signatures,Trampoline
s are cached in theSingleFunctionCompiler
.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
abrown updated PR #1517 from run-clif
to master
:
This resolves the work started in https://github.com/bytecodealliance/cranelift/pull/1231 and https://github.com/bytecodealliance/wasmtime/pull/1436. Cranelift filetests currently have the ability to run CLIF functions with a signature like
() -> b*
and check that the result is true under thetest run
directive. This PR adds the ability to call functions with arbitrary arguments and non-boolean returns and either print the result or check against a list of expected results:
run
commands look like; run: %add(2, 2) == 4
or; run: %add(2, 2) != 5
and verify that the executed CLIF function returns the expected value; print: %add(2, 2)
and print the result of the function to stdoutTo make this work, this PR compiles a single Cranelift
Function
into aCompiledFunction
using aSingleFunctionCompiler
. Because we will not know the signature of the function until runtime, we use aTrampoline
to place the values in the appropriate location for the calling convention; this should look a lot like what @alexcrichton is doing withVMTrampoline
in wasmtime (see https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/api/src/func.rs#L510-L526, https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/jit/src/compiler.rs#L260). To avoid re-compilingTrampoline
s for the same function signatures,Trampoline
s are cached in theSingleFunctionCompiler
.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
abrown updated PR #1517 from run-clif
to master
:
This resolves the work started in https://github.com/bytecodealliance/cranelift/pull/1231 and https://github.com/bytecodealliance/wasmtime/pull/1436. Cranelift filetests currently have the ability to run CLIF functions with a signature like
() -> b*
and check that the result is true under thetest run
directive. This PR adds the ability to call functions with arbitrary arguments and non-boolean returns and either print the result or check against a list of expected results:
run
commands look like; run: %add(2, 2) == 4
or; run: %add(2, 2) != 5
and verify that the executed CLIF function returns the expected value; print: %add(2, 2)
and print the result of the function to stdoutTo make this work, this PR compiles a single Cranelift
Function
into aCompiledFunction
using aSingleFunctionCompiler
. Because we will not know the signature of the function until runtime, we use aTrampoline
to place the values in the appropriate location for the calling convention; this should look a lot like what @alexcrichton is doing withVMTrampoline
in wasmtime (see https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/api/src/func.rs#L510-L526, https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/jit/src/compiler.rs#L260). To avoid re-compilingTrampoline
s for the same function signatures,Trampoline
s are cached in theSingleFunctionCompiler
.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
abrown updated PR #1517 from run-clif
to master
:
This resolves the work started in https://github.com/bytecodealliance/cranelift/pull/1231 and https://github.com/bytecodealliance/wasmtime/pull/1436. Cranelift filetests currently have the ability to run CLIF functions with a signature like
() -> b*
and check that the result is true under thetest run
directive. This PR adds the ability to call functions with arbitrary arguments and non-boolean returns and either print the result or check against a list of expected results:
run
commands look like; run: %add(2, 2) == 4
or; run: %add(2, 2) != 5
and verify that the executed CLIF function returns the expected value; print: %add(2, 2)
and print the result of the function to stdoutTo make this work, this PR compiles a single Cranelift
Function
into aCompiledFunction
using aSingleFunctionCompiler
. Because we will not know the signature of the function until runtime, we use aTrampoline
to place the values in the appropriate location for the calling convention; this should look a lot like what @alexcrichton is doing withVMTrampoline
in wasmtime (see https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/api/src/func.rs#L510-L526, https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/jit/src/compiler.rs#L260). To avoid re-compilingTrampoline
s for the same function signatures,Trampoline
s are cached in theSingleFunctionCompiler
.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
abrown updated PR #1517 from run-clif
to master
:
This resolves the work started in https://github.com/bytecodealliance/cranelift/pull/1231 and https://github.com/bytecodealliance/wasmtime/pull/1436. Cranelift filetests currently have the ability to run CLIF functions with a signature like
() -> b*
and check that the result is true under thetest run
directive. This PR adds the ability to call functions with arbitrary arguments and non-boolean returns and either print the result or check against a list of expected results:
run
commands look like; run: %add(2, 2) == 4
or; run: %add(2, 2) != 5
and verify that the executed CLIF function returns the expected value; print: %add(2, 2)
and print the result of the function to stdoutTo make this work, this PR compiles a single Cranelift
Function
into aCompiledFunction
using aSingleFunctionCompiler
. Because we will not know the signature of the function until runtime, we use aTrampoline
to place the values in the appropriate location for the calling convention; this should look a lot like what @alexcrichton is doing withVMTrampoline
in wasmtime (see https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/api/src/func.rs#L510-L526, https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/jit/src/compiler.rs#L260). To avoid re-compilingTrampoline
s for the same function signatures,Trampoline
s are cached in theSingleFunctionCompiler
.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
abrown requested bnjbvr for a review on PR #1517.
abrown updated PR #1517 from run-clif
to master
:
This resolves the work started in https://github.com/bytecodealliance/cranelift/pull/1231 and https://github.com/bytecodealliance/wasmtime/pull/1436. Cranelift filetests currently have the ability to run CLIF functions with a signature like
() -> b*
and check that the result is true under thetest run
directive. This PR adds the ability to call functions with arbitrary arguments and non-boolean returns and either print the result or check against a list of expected results:
run
commands look like; run: %add(2, 2) == 4
or; run: %add(2, 2) != 5
and verify that the executed CLIF function returns the expected value; print: %add(2, 2)
and print the result of the function to stdoutTo make this work, this PR compiles a single Cranelift
Function
into aCompiledFunction
using aSingleFunctionCompiler
. Because we will not know the signature of the function until runtime, we use aTrampoline
to place the values in the appropriate location for the calling convention; this should look a lot like what @alexcrichton is doing withVMTrampoline
in wasmtime (see https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/api/src/func.rs#L510-L526, https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/jit/src/compiler.rs#L260). To avoid re-compilingTrampoline
s for the same function signatures,Trampoline
s are cached in theSingleFunctionCompiler
.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
abrown updated PR #1517 from run-clif
to master
:
This resolves the work started in https://github.com/bytecodealliance/cranelift/pull/1231 and https://github.com/bytecodealliance/wasmtime/pull/1436. Cranelift filetests currently have the ability to run CLIF functions with a signature like
() -> b*
and check that the result is true under thetest run
directive. This PR adds the ability to call functions with arbitrary arguments and non-boolean returns and either print the result or check against a list of expected results:
run
commands look like; run: %add(2, 2) == 4
or; run: %add(2, 2) != 5
and verify that the executed CLIF function returns the expected value; print: %add(2, 2)
and print the result of the function to stdoutTo make this work, this PR compiles a single Cranelift
Function
into aCompiledFunction
using aSingleFunctionCompiler
. Because we will not know the signature of the function until runtime, we use aTrampoline
to place the values in the appropriate location for the calling convention; this should look a lot like what @alexcrichton is doing withVMTrampoline
in wasmtime (see https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/api/src/func.rs#L510-L526, https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/jit/src/compiler.rs#L260). To avoid re-compilingTrampoline
s for the same function signatures,Trampoline
s are cached in theSingleFunctionCompiler
.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
abrown updated PR #1517 from run-clif
to master
:
This resolves the work started in https://github.com/bytecodealliance/cranelift/pull/1231 and https://github.com/bytecodealliance/wasmtime/pull/1436. Cranelift filetests currently have the ability to run CLIF functions with a signature like
() -> b*
and check that the result is true under thetest run
directive. This PR adds the ability to call functions with arbitrary arguments and non-boolean returns and either print the result or check against a list of expected results:
run
commands look like; run: %add(2, 2) == 4
or; run: %add(2, 2) != 5
and verify that the executed CLIF function returns the expected value; print: %add(2, 2)
and print the result of the function to stdoutTo make this work, this PR compiles a single Cranelift
Function
into aCompiledFunction
using aSingleFunctionCompiler
. Because we will not know the signature of the function until runtime, we use aTrampoline
to place the values in the appropriate location for the calling convention; this should look a lot like what @alexcrichton is doing withVMTrampoline
in wasmtime (see https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/api/src/func.rs#L510-L526, https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/jit/src/compiler.rs#L260). To avoid re-compilingTrampoline
s for the same function signatures,Trampoline
s are cached in theSingleFunctionCompiler
.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
abrown updated PR #1517 from run-clif
to master
:
This resolves the work started in https://github.com/bytecodealliance/cranelift/pull/1231 and https://github.com/bytecodealliance/wasmtime/pull/1436. Cranelift filetests currently have the ability to run CLIF functions with a signature like
() -> b*
and check that the result is true under thetest run
directive. This PR adds the ability to call functions with arbitrary arguments and non-boolean returns and either print the result or check against a list of expected results:
run
commands look like; run: %add(2, 2) == 4
or; run: %add(2, 2) != 5
and verify that the executed CLIF function returns the expected value; print: %add(2, 2)
and print the result of the function to stdoutTo make this work, this PR compiles a single Cranelift
Function
into aCompiledFunction
using aSingleFunctionCompiler
. Because we will not know the signature of the function until runtime, we use aTrampoline
to place the values in the appropriate location for the calling convention; this should look a lot like what @alexcrichton is doing withVMTrampoline
in wasmtime (see https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/api/src/func.rs#L510-L526, https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/jit/src/compiler.rs#L260). To avoid re-compilingTrampoline
s for the same function signatures,Trampoline
s are cached in theSingleFunctionCompiler
.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
bnjbvr submitted PR Review.
bnjbvr submitted PR Review.
bnjbvr created PR Review Comment:
I think we don't need to worry about the clone, this is an error path, so not perf sensitive. Could it be
e.to_string()
to avoid the macro use?
bnjbvr created PR Review Comment:
Instead, could this look if trimmed is exactly run or print? I don't see the value in the ambiguity. If you agree with this, then we could rename this function
is_run_or_print_command
(since otherwise, there's a "run_command" called "run" and another called "print", which is a bit confusing).In addition to this, could this return the command it found (so an
Option
, withNone
equivalent to current's false), instead of letting the caller clean up comments again and analyze the value?
bnjbvr created PR Review Comment:
Do we need to trim comments again here? There can't be a comment within a comment, so this would only removed spaces at the start of
comment.text
, right? If so, and if we want this, could we do it explicitly withtrim_start_matches(" ")
instead?
bnjbvr created PR Review Comment:
No need to worry about cloning here, it's not a perf-sensitive path. Can you use
e.to_string()
though?
bnjbvr created PR Review Comment:
Could we just do a write here, using a transmute? It avoids the indirection through
Trampoline::write_value_to
, which is a bit unsettling.If we did the same for reads, then the need for the
Trampoline
data structure is much lower, and could probably be avoided. Or we could hide the writing and reading into a different newUnboxedValues
struct type (that'd be a vec<u128>); then theslot_size
could be an attribute of this struct, a const func returning the size of the values it's storing (and then we can remove a bunch of comments, and have more confidence in the size being sync'd with the storage type). What do you think?
bnjbvr created PR Review Comment:
Could it also check that the host architecture is equal to the requested ISA's architecture?
bnjbvr created PR Review Comment:
Could we clone the function's signature before, since it's the only field that's used after (and it's cheap), and then pass the ownership to
compile
?
abrown submitted PR Review.
abrown created PR Review Comment:
Those checks should already exist at a higher level, e.g.
test_run.rs
, and I didn't want to limit this code too much because there are cases (x86 32-bit vs 64-bit) where multiple Cranelift ISAs could run on the same machine.
abrown submitted PR Review.
abrown created PR Review Comment:
Good idea... done.
abrown updated PR #1517 from run-clif
to master
:
This resolves the work started in https://github.com/bytecodealliance/cranelift/pull/1231 and https://github.com/bytecodealliance/wasmtime/pull/1436. Cranelift filetests currently have the ability to run CLIF functions with a signature like
() -> b*
and check that the result is true under thetest run
directive. This PR adds the ability to call functions with arbitrary arguments and non-boolean returns and either print the result or check against a list of expected results:
run
commands look like; run: %add(2, 2) == 4
or; run: %add(2, 2) != 5
and verify that the executed CLIF function returns the expected value; print: %add(2, 2)
and print the result of the function to stdoutTo make this work, this PR compiles a single Cranelift
Function
into aCompiledFunction
using aSingleFunctionCompiler
. Because we will not know the signature of the function until runtime, we use aTrampoline
to place the values in the appropriate location for the calling convention; this should look a lot like what @alexcrichton is doing withVMTrampoline
in wasmtime (see https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/api/src/func.rs#L510-L526, https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/jit/src/compiler.rs#L260). To avoid re-compilingTrampoline
s for the same function signatures,Trampoline
s are cached in theSingleFunctionCompiler
.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
abrown submitted PR Review.
abrown created PR Review Comment:
Yeah, this is a good direction. These weird
trimmed_comment_chars
andis_potential_run_command
functions were trying to do some lookahead to see if we actually needed to really parse the comment. I moved that logic intoparse_run_command
(which is in the parser module, where this functionality should be) and made it returnParseResult<Option<RunCommand>>
instead ofParseResult<RunCommand>
. The signature is a bit more complex but I think it is headed more in the direction you are suggesting.
bjorn3 submitted PR Review.
bjorn3 created PR Review Comment:
32bit x86 doesn't work in 64bit processes.
abrown submitted PR Review.
abrown created PR Review Comment:
I like having the
Trampoline
structure around to know what we are talking about; otherwise we have anMmap
floating around that is implicitly a trampoline. But that could be a type alias, I guess. I think yourUnboxedValues
makes sense and I started down this road but I'm not too confident about the transmute stuff--I will ping you on Zulip to see what you think.
abrown updated PR #1517 from run-clif
to master
:
This resolves the work started in https://github.com/bytecodealliance/cranelift/pull/1231 and https://github.com/bytecodealliance/wasmtime/pull/1436. Cranelift filetests currently have the ability to run CLIF functions with a signature like
() -> b*
and check that the result is true under thetest run
directive. This PR adds the ability to call functions with arbitrary arguments and non-boolean returns and either print the result or check against a list of expected results:
run
commands look like; run: %add(2, 2) == 4
or; run: %add(2, 2) != 5
and verify that the executed CLIF function returns the expected value; print: %add(2, 2)
and print the result of the function to stdoutTo make this work, this PR compiles a single Cranelift
Function
into aCompiledFunction
using aSingleFunctionCompiler
. Because we will not know the signature of the function until runtime, we use aTrampoline
to place the values in the appropriate location for the calling convention; this should look a lot like what @alexcrichton is doing withVMTrampoline
in wasmtime (see https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/api/src/func.rs#L510-L526, https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/jit/src/compiler.rs#L260). To avoid re-compilingTrampoline
s for the same function signatures,Trampoline
s are cached in theSingleFunctionCompiler
.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
bnjbvr requested bnjbvr for a review on PR #1517.
bnjbvr submitted PR Review.
bnjbvr submitted PR Review.
bnjbvr created PR Review Comment:
nit: can we put the
unsafe
within thepush
, to make it clear that the push itself isn't an issue?
bnjbvr created PR Review Comment:
This will manifest as a panic when running a test, right? Is there a way to propagate this as an error to the test runner, with the right file location, instead?
abrown created PR Review Comment:
Parser::parse_data_value
actually does that type checking before we ever get here; I'm going to change this to anassert!
since that more clearly indicates the intent of this check.
abrown submitted PR Review.
abrown updated PR #1517 from run-clif
to master
:
This resolves the work started in https://github.com/bytecodealliance/cranelift/pull/1231 and https://github.com/bytecodealliance/wasmtime/pull/1436. Cranelift filetests currently have the ability to run CLIF functions with a signature like
() -> b*
and check that the result is true under thetest run
directive. This PR adds the ability to call functions with arbitrary arguments and non-boolean returns and either print the result or check against a list of expected results:
run
commands look like; run: %add(2, 2) == 4
or; run: %add(2, 2) != 5
and verify that the executed CLIF function returns the expected value; print: %add(2, 2)
and print the result of the function to stdoutTo make this work, this PR compiles a single Cranelift
Function
into aCompiledFunction
using aSingleFunctionCompiler
. Because we will not know the signature of the function until runtime, we use aTrampoline
to place the values in the appropriate location for the calling convention; this should look a lot like what @alexcrichton is doing withVMTrampoline
in wasmtime (see https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/api/src/func.rs#L510-L526, https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/jit/src/compiler.rs#L260). To avoid re-compilingTrampoline
s for the same function signatures,Trampoline
s are cached in theSingleFunctionCompiler
.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
abrown merged PR #1517.
Last updated: Dec 23 2024 at 12:05 UTC