| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
This is needed to make sure globals are printed before element segments,
where `global.get` can appear both as offset and an expression.
|
| |
|
|
|
|
|
|
| |
Adds an option to wasm-split to allow the user to specify the initial table size
for both instrumenting and splitting use cases. In the short term this will be
used in Emscripten SPLIT_MODULE + dynamic linking workflow to ensure that the
expected table size baked into the JS works for both the instrumented and the
primary split modules. In the longer term this may be replaced with a more
elegant mechanism for making the JS works in both cases.
|
| |
|
|
|
|
|
|
|
| |
During module splitting, a map is constructed from internal names to their
corresponding export names. This code previously did not take into account the
fact that the same internal name may be used by different kinds of
entities (e.g. a table and a memory may have the same internal name), which
resulted in the secondary module incorrectly using the same import name for all
of the entities that shared an internal name. This PR fixes the problem by
including the ExternalKind of the entity in the keys of the export map.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Calculate a checksum of the original uninstrumented module and emit it as part
of the profile data. When reading the profile, compare the checksum it contains
to the checksum of the module that is being split. Error out if the module being
split is not the same as the module that was originally instrumented.
Also fixes a bug in how the profile data was being read. When `char` is signed,
bytes read from the profile were being incorrectly sign extended. We had not
noticed this before because the profiles we have tested have contained only
small-valued counts.
|
| |
|
|
|
|
| |
Read the profiles produced by wasm-split's instrumentation to guide splitting.
In this initial implementation, all functions that the profile shows to have
been called are kept in the initial module. In the future, users may be able to
tune this so that functions that are run later will still be split out.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Implement an instrumentation pass that records the timestamp at which each
defined function is first called. Timestamps are not actual time, but rather
snapshots of a monotonically increasing counter. The instrumentation exports a
function that the embedder can call to dump the profile data into a memory
buffer at a given offset and size. The function returns the total size of the
profile data so the embedder can know how much to read out of the buffer or how
much it needs to grow the buffer.
Parsing and using the profile is left as future work, as is recording a hash of
the input file that will be used to guard against accidentally instrumenting one
module and trying to use the resulting profile to split a different module.
|
|
|
Implement an initial version of the wasm-split tool, which splits modules into a
primary module and a secondary module that can be instantiated after the primary
module. Eventually, this tool will be able to not only split modules, but also
instrument modules to collect profiles that will be able to guide later
splitting. In this initial version, however, wasm-split can neither perform
instrumentation nor consume any kind of profile data.
Despite those shortcomings, this initial version of the tool is already able to
perform module splitting according to function lists manually provided by the
user via the command line. Follow-up PRs will implement the stubbed out
instrumentation and profile consumption functionality.
|
