Update the documentation for the merger, and also for various changes in
Cranelift. Remove some old obsolete documentation, and convert the remaining
Sphinx files to Markdown. Some of the remaining content is still out of
date, but this is a step forward.
This is a rebase of [1]. In the long term, we'll want to simplify these
analysis passes. For now, this is simple and will reduce the number of
instructions processed in certain cases.
[1] https://github.com/bytecodealliance/cranelift/pull/866
The current interface of `cranelift-module` requires consumers who want
to be informed about traps to discover that information through
`Module::Product`, which is backend-specific. Since it's advantageous
to manipulate this information in a backend-agnostic way, this patch
changes `Module::define_function{,_bytes}` to return information about
the traps contained in the function being defined.
* rename PassiveElemIndex to ElemIndex and same for PassiveDataIndex (#1411)
* rename PassiveDataIndex to DataIndex
* rename PassiveElemIndex to ElemIndex
* Apply renamings to wasmtime as well
* Run rustfmt
Co-authored-by: csmoe <csmoe@msn.com>
wasmtime is covered by oss-fuzz which should cover large swaths of
cranelift as well, so let's remove that from CI and add it back later if
it's necessary.
This is useful for me because I name the module after the file, which
comes from the filesystem and may not be valid UTF8.
This change is backwards-compatible.
To fix this case that may take forever to compile:
function %a(){
ebb477777777:
}
We decide to define a maximum threshold for the number of blocks in functions.
Based on a large WASM program (https://github.com/mozilla/perf-automation/blob/master/benchmarks/wasm-misc/AngryBots.wasm),
its IR functions does not exceed 1414 blocks. A number 100 times greater (100,000 blocks) seems (currently) enough to define our maximum threshold.
To make this quick benchmark the cranelift-wasm/src/func_translator.rs file has been modified like this:
static mut MAX: usize = 0;
pub fn translate_from_reader<FE: FuncEnvironment + ?Sized>(...) {
[...]
builder.finalize();
// the compiler is single threaded
unsafe {
if func.dfg.num_ebbs() > MAX {
MAX = func.dfg.num_ebbs();
println!("MAX {}", MAX);
}
}
Ok(())
}
* move trap site definitions into cranelift-module
`cranelift-faerie` and `cranelift-object` already have identical
definitions of structures to represent trap sites. We might as well
merge them ahead of work to define functions via a raw slice of bytes
with associated traps, which will need some kind of common structure for
representing traps anyway.
* cranelift-module: add `define_function_bytes` interface
This interface is useful when the client needs to precisely specify the
ordering of bytes in a particular function.
* add comment about saving files for `perf`
* use new zeroinit API for faerie
* use bss for cranelift-object
* don't crash when initializing bss
* fix formatting
* Improve code locality
Co-Authored-By: Philip Craig <philipjcraig@gmail.com>
* use `as` instead of try_into() for usize -> u64
* don't allocate unnecessarily in `faerie`
Co-authored-by: Philip Craig <philipjcraig@gmail.com>
