| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
gimli-rs and perhaps also the spec require a final 0
to terminate the list. LLVM itself is fine without that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Multiple tables appear to be emitted when linking files
together. This fixes our support for that, which did not
update their size properly. This required patching the
YAML emitting code from LLVM in order to measure
the size and then emit it, as that code is apparently
not designed to handle changes in line table
contents.
Other minor fixes:
* Set the flags for our dwarfdump command to emit
the same as llvm-dwarfdump does with -v -all.
* Add support for a few more opcodes,
set_discriminator, set_basic_block, fixed_advance_pc,
set_isa.
* Handle a compile unit without abbreviations in the
YAML code (again, apparently not something this
LLVM code was intended to do).
* Handle a compile unit with zero entries in the
YAML code (ditto).
* Properly set the AddressSize - we use the
DWARFContext in a different way than LLVM expects,
apparently.
With this the emscripten test suite passes with
-gforce_dwarf without crashing.
My overall impression so from the the YAML code is
that it probably isn't a long-term solution for us. Perhaps
it may end up being scaffolding, that is, we can
replace it with our own code eventually that is based
on it, and remove most of the LLVM code. Before
deciding that we should get everything working first,
and this seems like the quickest path there.
|
| |
|
|
|
| |
This makes push and pop instructions not printed in the stack IR format
to make it valid wat form. Push and pop are still generated in the stack
IR in memory but not printed in the text format.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The analysis currently uses a dense matrix. If there are >65535
locals then the indexes don't fit in a 32-bit type like a wasm32
index, which led to overflows and incorrect behavior. To avoid
that, don't run passes with liveness analysis for now if they have
that many locals.
Note that skipping coalesce-locals (the main liveness-using
pass) is not that bad, as we run it more than once, and it's
likely that even if the first must be skipped, we can still run
the second (which is after simplify- and reorder-locals, which
can greatly reduce the local count).
Fixes #2559
|
| |
|
|
|
|
|
|
|
|
|
| |
We have not been generating push and pop instructions in the stack IR.
Even though they are not written in binary, they have to be in the stack
IR to match the number of inputs and outputs of instructions.
Currently `BinaryenIRWriter` is used both for stack IR generation and
binary generation, so we should emit those instructions in
`BinaryenIRWriter`. `BinaryenIRToBinaryWriter`, which inherits
`BinaryenIRWriter`, does not do anything for push and pop instructions,
so they are still not emitted in binary.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This adds support for the reference type proposal. This includes support
for all reference types (`anyref`, `funcref`(=`anyfunc`), and `nullref`)
and four new instructions: `ref.null`, `ref.is_null`, `ref.func`, and
new typed `select`. This also adds subtype relationship support between
reference types.
This does not include table instructions yet. This also does not include
wasm2js support.
Fixes #2444 and fixes #2447.
|
| |
|
|
| |
movements (#2552)
|
| |
|
|
| |
Because `memory.size` returns the size in number of pages, we have to
multiply the size with the page size when converting `memory.init`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this, we can update DWARF debug line info properly as
we write a new binary.
To do that we track binary locations as we write. Each
instruction is mapped to the location it is written to. We
must also adjust them as we move code around because
of LEB optimization (we emit a function or a section
with a 5-byte LEB placeholder, the maximal size; later
we shrink it which is almost always possible).
writeDWARFSections() now takes a second param, the new
locations of instructions. It then maps debug line info from the
original offsets in the binary to the new offsets in the binary
being written.
The core logic for updating the debug line section is in
wasm-debug.cpp. It basically tracks state machine logic
both to read the existing debug lines and to emit the new
ones. I couldn't find a way to reuse LLVM code for this, but
reading LLVM's code was very useful here.
A final tricky thing we need to do is to update the DWARF
section's internal size annotation. The LLVM YAML writing
code doesn't do that for us. Luckily it's pretty easy, in
fixEmittedSection we just update the first 4 bytes in place
to have the section size, after we've emitted it and know
the size.
This ignores debug lines with a 0 in the line, col, or addr,
see WebAssembly/debugging#9 (comment)
This ignores debug line offsets into the middle of
instructions, which LLVM sometimes emits for some
reason, see WebAssembly/debugging#9 (comment)
Handling that would likely at least double our memory
usage, which is unfortunate - we are run in an LTO manner,
where the entire app's DWARF is present, and it may be
massive. I think we should see if such odd offsets are
a bug in LLVM, and if we can fix or prevent that.
This does not emit "special" opcodes for debug lines. Those
are purely an optimization, which I wanted to leave for
later. (Even without them we decrease the size quite a lot,
btw, as many lines have 0s in them...)
This adds some testing that shows we can load and save
fib2.c and fannkuch.cpp properly. The latter includes more
than one function and has nontrivial code.
To actually emit correct offsets a few minor fixes are
done here:
* Fix the code section location tracking during reading -
the correct offset we care about is the body of the code
section, not including the section declaration and size.
* Fix wasm-stack debug line emitting. We need to update
in BinaryInstWriter::visit(), that is, right before writing
bytes for the instruction. That differs from
* BinaryenIRWriter::visit which is a recursive function
that also calls the children - so the offset there would be
of the first child. For some reason that is correct with
source maps, I don't understand why, but it's wrong for
DWARF...
* Print code section offsets in hex, to match other tools.
Remove DWARFUpdate pass, which was useful for testing
temporarily, but doesn't make sense now (it just updates without
writing a binary).
cc @yurydelendik
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Optionally track the binary format code section offsets,
that is, when loading a binary, remember where each IR
node was read from. This is necessary for DWARF
debug info, as these are the offsets DWARF refers to.
(Note that eventually we may want to do something
else, like first read the DWARF and only then add
debug info annotations into the IR in a more LLVM-like
manner, but this is more straightforward and should be
enough to update debug lines and ranges).
This tracking adds noticeable overhead - every single
IR node adds an entry in a map - so avoid it unless
actually necessary. Specifically, if the user passes in
-g and there are actually DWARF sections in the
binary, and we are not about to remove those sections,
then we need it.
Print binary format code section offsets in text, when
printing with -g. This will help debug and test dwarf
support. It looks like
;; code offset: 0x7
as an annotation right before each node.
Also add support for -g in wasm-opt tests (unlike
a pass, it has just one - as a prefix).
Helps #2400
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This imports LLVM code for DWARF handling. That code has the
Apache 2 license like us. It's also the same code used to
emit DWARF in the common toolchain, so it seems like a safe choice.
This adds two passes: --dwarfdump which runs the same code LLVM
runs for llvm-dwarfdump. This shows we can parse it ok, and will
be useful for debugging. And --dwarfupdate writes out the DWARF
sections (unchanged from what we read, so it just roundtrips - for
updating we need #2515).
This puts LLVM in thirdparty which is added here.
All the LLVM code is behind USE_LLVM_DWARF, which is on
by default, but off in JS for now, as it increases code size by 20%.
This current approach imports the LLVM files directly. This is not
how they are intended to be used, so it required a bunch of
local changes - more than I expected actually, for the platform-specific
stuff. For now this seems to work, so it may be good enough, but
in the long term we may want to switch to linking against libllvm.
A downside to doing that is that binaryen users would need to
have an LLVM build, and even in the waterfall builds we'd have a
problem - while we ship LLVM there anyhow, we constantly update
it, which means that binaryen would need to be on latest llvm all
the time too (which otherwise, given DWARF is quite stable, we
might not need to constantly update).
An even larger issue is that as I did this work I learned about how
DWARF works in LLVM, and while the reading code is easy to
reuse, the writing code is trickier. The main code path is heavily
integrated with the MC layer, which we don't have - we might want
to create a "fake MC layer" for that, but it sounds hard. Instead,
there is the YAML path which is used mostly for testing, and which
can convert DWARF to and from YAML and from binary. Using
the non-YAML parts there, we can convert binary DWARF to
the YAML layer's nice Info data, then convert that to binary. This
works, however, this is not the path LLVM uses normally, and it
supports only some basic DWARF sections - I had to add ranges
support, in fact. So if we need more complex things, we may end
up needing to use the MC layer approach, or consider some other
DWARF library. However, hopefully that should not affect the core
binaryen code which just calls a library for DWARF stuff.
Helps #2400
|
| |
|
|
|
|
|
|
|
|
|
| |
This does two things:
- Restore `visitDataDrop` handler deleted in #2529, but now we convert
invalid `data.drop`s to not `unreachable` but `nop`. This conforms to
the revised spec that `data.drop` on the active segment can be treated
as a nop.
- Make `visitMemoryInit` trap if offset or size are not equal to 0 or if
the dest address is out of bounds. Otherwise drop all its argument.
Fixes #2535.
|
| |
|
|
|
|
| |
Currently `ModuleUtils::clearModule` does not clear `exists` flags in
the memory and table, and running RoundTrip pass on any module that has
a memory or a table fails as a result. This creates `clear` function in
`Memory` and `Table` and makes `clearModule` call them.
|
| |
|
|
|
|
|
| |
- Remove a function from memory-packing_all-features.wast, because it
does not test anything meaningful after #2529.
- Rename a test file to use `--all-features`; it started failing I guess
because `exnref` requires also reference type features, but not sure
why it was OK so far.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements recent bulk memory spec changes
(WebAssembly/bulk-memory-operations#126) in Binaryen. Now `data.drop` is
equivalent to shrinking a segment size to 0, and dropping already
dropped segments or active segments (which are thought to be dropped in
the beginning) is treated as a no-op. And all bounds checking is
performed in advance, so partial copying/filling/initializing does not
occur.
I tried to implement `visitDataDrop` in the interpreter as
`segment.data.clear();`, which is exactly what the revised spec says. I
didn't end up doing that because this also deletes all contents from
active segments, and there are cases we shouldn't do that:
- `wasm-ctor-eval` shouldn't delete active segments, because it will
store the changed contents back into segments
- When `--fuzz-exec` is given to `wasm-opt`, it runs the module and
compare the execution call results before and after transformations.
But if running a module will nullify all active segments, applying
any transformation to the module or re-running it does not make any
sense.
|
| |
|
|
|
|
| |
contains the passes (#2532)
We already supported this, but required that the filename be a number.
This lets the name be anything, and we check if *.passes exists for it.
|
| |
|
|
|
|
|
| |
When the expression type is none, it does not seem to be necessary to
make it a prelude and insert a nop. This also results in unnecessary
blocks that contains an expression with a nop, which can be reduced to
just the expression. This also adds some newlines to improve
readability.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Function signatures were previously redundantly stored on Function
objects as well as on FunctionType objects. These two signature
representations had to always be kept in sync, which was error-prone
and needlessly complex. This PR takes advantage of the new ability of
Type to represent multiple value types by consolidating function
signatures as a pair of Types (params and results) stored on the
Function object.
Since there are no longer module-global named function types,
significant changes had to be made to the printing and emitting of
function types, as well as their parsing and manipulation in various
passes.
The C and JS APIs and their tests also had to be updated to remove
named function types.
|
| |
|
|
|
|
| |
This fixes the parent-child relationship computation in `DataFlow.Graph`
when there is a loop. This wasn't discovered until now because this is
used in Souperify and Souperify only runs after Flatten pass, which
produces redundant blocks between inside and outside of a loop.
|
| |
|
|
|
|
| |
This pass writes and reads the module. This shows the effects
of converting to and back from the binary format, and will be
useful in testing dwarf debug support (where we'll need to see
that writing and reading a module preserves debug info properly).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently `none` and `unreachable` types are stored as the same empty
`{}` in src/wasm/wasm-type.cpp. This makes `Type::operator<` incorrectly
when given `none` and `unreachable`, because it expands both given types
and lexicographically compare them, when both of the expanded vector
will be empty.
This was found by the fuzzer. This line in `Modder::visitExpression`
tries to retrieve candidates of the same type. Because we can't really
compare these two types, if you give `unreachable` as the key,
candidates of `none` type can be returned. This generates incorrect code
that ends up failing in validation in a very weird way.
It was hard to generate a small testcase to trigger this part because it
was found by generating fuzzed code from a random data file. But I guess
this fix is pretty straightforward.
Fixes #2512.
|
| |
|
|
|
|
|
|
|
|
|
| |
The `$` is not actually part of the name, its the marker that starts
a name in the wat format. It can be confusing to see it show up when
doing `cerr << name`, for example.
This change has Print.cpp add the `$` which seem like the right place
to do this. Plus it revealed a bunch of places where were not calling
printName to escape all the names we were printing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current `<<` operator on `Literal` prints `[type].const` with it. But
`[type].const` is rather an instruction than a literal itself, and
printing it with the literals makes less sense when we later have
literals whose type don't have `const` instructions (such as reference
types).
This patch
- Makes `<<` operator on `Literal` print only its value
- Makes wasm-shell's shell interface comply with the spec interpreter's
printing format (`value : type`).
- Prints wasm-shell's `[trap]` message to stderr
These make all `fix_` routines for spec tests in check.py unnecessary.
|
| |
|
|
|
|
|
|
|
| |
This is the start of a larger refactoring to remove FunctionType entirely and
store types and signatures directly on the entities that use them. This PR
updates BrOnExn and Events to remove their use of FunctionType and makes the
BinaryWriter traverse the module and collect types rather than using the global
FunctionType list. While we are collecting types, we also sort them by frequency
as an optimization. Remaining uses of FunctionType in Function, CallIndirect,
and parsing will be removed in a future PR.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Adds the ability to create multivalue types from vectors of concrete value
types. All types are transparently interned, so their representation is still a
single uint32_t. Types can be extracted into vectors of their component parts,
and all the single value types expand into vectors containing themselves.
Multivalue types are not yet used in the IR, but their creation and inspection
functionality is exposed and tested in the C and JS APIs.
Also makes common type predicates methods of Type and improves the ergonomics of
type printing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clang/llvm introduce __original_main as a workaround for
the fact that main may have different signatures. A downside
to that is that users get it in stack traces, which is confusing.
In -O2 and above we normally inline __original_main anyhow,
but as this is for debugging, non-optimized builds matter too,
so add a pass for this.
The implementation is trivial, just call doInling. However we
must check some corner cases first.
Bonus minor fixes to FindAllPointers, which unnecessarily
created an object to get the class Id (which is not valid
for all classes), and that it didn't take the input by
reference properly, which meant we couldn't get the
pointer to the function body's toplevel.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This pass strips DWARF debug sections, but not other debug
sections. This is useful when emitting source maps, as we do
need the SourceMapURL section, but the DWARF sections are
not longer necessary (and we've seen a testcase where they
are massively large, so big the wasm can't even be loaded in
a browser...).
Also contains a trivial one-line fix in --extract-function which
was necessary to create the testcase here: that pass extracts
a function from a wasm file (like llvm-extract) but it didn't check
if an export already existed for the function.
|
| |
|
|
|
| |
Adds the AssemblyScript-specific passes post-assemblyscript
and post-assemblyscript-finalize, eliminating redundant ARC-style
retain/release patterns conservatively emitted by the compiler.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When we see invoke_ calls in emscripten-generated code, we know
they call into JS just to do a try-catch for exceptions. If the target being
called cannot throw, which we check in a whole-program manner, then
we can simply skip the invoke.
I confirmed that this fixes the regression in emscripten-core/emscripten#9817 (comment)
(that is, with this optimization, upstream is around as fast as fastcomp).
When we have native wasm exception handling, this can be
extended to optimize that as well.
|
| |
|
|
|
| |
The original is necessary if we want to pass it to wasm, where it will be called
directly, without JS legalization. For example the JS dynamic loader in
emscripten needs this, emscripten-core/emscripten#9562
|
| |
|
|
|
|
|
| |
- When a catch body is a block, call its `finalize` function with the
correct type
- Don't create a block when there's one instruction in a catch body
- Remove `makeCatch` from gen-s-parser.py; it's not necessary
- Fix a test case that has a `catch` without `try`
|
| | |
|
| |
|
|
|
|
|
|
|
| |
- Adds `items` function for `FeatureOptions` so we can get a vector of
eligible types
- Replaces hardcoded enumeration of MVP types with `getConcreteTypes`,
which also adds v128 type to the list if SIMD is enabled
- Removes `getType()` function; this does not seem to be used anywhere
- Renames `vectorPick` with `pick`
- Use the absolute path for d8 in the fuzzer
|
| |
|
| |
Fixes #2417
|
| |
|
| |
PostWalker traversal should visit its value.
|
| |
|
|
| |
Like an `If`, `Try` construct is reachable when either its try body or
catch body is reachable. This adds support for that.
|
| |
|
|
|
| |
Previously RemoveUnusedModuleElements pass only preserved exported
events and did not preserve events used in `throw` and `br_on_exn`
instructions. This fixes it.
|
| |
|
| |
This fixes a crash when programs containing load_splats are optimized.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These passes are meant to be run after Asyncify has been run, they modify the
output. We can assume that we will always unwind if we reach an import, or
that we will never unwind, etc.
This is meant to help with lazy code loading, that is, the ability for an
initially-downloaded wasm to not contain all the code, and if code not present
there is called, we download all the rest and continue with that. That could
work something like this:
* The wasm is created. It contains calls to a special import for lazy code
loading.
* Asyncify is run on it.
* The initially downloaded wasm is created by running
--mod-asyncify-always-and-only-unwind: if the special import for lazy code
loading is called, we will definitely unwind, and we won't rewind in this binary.
* The lazily downloaded wasm is created by running --mod-asyncify-never-unwind:
we will rewind into this binary, but no longer need support for unwinding.
(Optionally, there could also be a third wasm, which has not had Asyncify run
on it, and which we'd swap to for max speed.)
These --mod-asyncify passes allow the optimizer to do a lot of work, especially
for the initially downloaded wasm if we have lots of calls to the lazy code
loading import. In that case the optimizer will see that those calls unwind,
which means the code after them is not reached, potentially making lots of code
dead and removable.
|
| |
|
|
| |
`exnref` is enabled by not reference type feature but exception handling
feature. Sorry that I missed this in #2377.
|
| |
|
|
|
| |
`pop` is not a real instruction and automatically generated when reading
binary and deleted when writing binary, so this does not work with
instrumentation.
|
| | |
|
| |
|
| |
This adds support for anyref and exnref types in InstrumentLocals pass.
|
| |
|
|
|
| |
We've had an option to set the location of the sbrk ptr, but not the value.
Applying the value as well is necessary for standalone wasm, as otherwise we set
it in JS.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This optimizes stuff like
(global.set $x (i32.const 123))
(global.get $x)
into
(global.set $x (i32.const 123))
(i32.const 123)
This doesn't help much with LLVM output as it's rare to use globals (except for the stack pointer, and that's already well optimized), but it may help on general wasm. It can also help with Asyncify that does use globals extensively.
|
| |
|
|
|
| |
With the optional asserts, we throw if we see an unwind begin in code that we thought could never unwind (say, because the user incorrectly blacklisted it).
Helps with emscripten-core/emscripten#9389
|
| |
|
|
|
| |
Properly handle fastcomp wasm safe heap: emscripten_get_sbrk_ptr is an asm.js library function, which means it is inside the wasm after asm2wasm, and exported. Find it via the export.
|
| |
|
|
|
|
|
| |
Currently emscripten links the wasm, then links the JS, then computes the final static allocations and in particular the location of the sbrk ptr (i.e. the location in memory of the brk location). Emscripten then imports that into the asm.js or wasm as env.DYNAMICTOP_PTR. However, this didn't work in the wasm backend where we didn't have support for importing globals from JS, so we implement sbrk in JS.
I am proposing that we change this model to allow us to write sbrk in C and compile it to wasm. To do so, that C code can import an extern C function, emscripten_get_sbrk_ptr(), which basically just returns that location. The PostEmscripten pass can even apply that value at compile time, so we avoid the function call, and end up in the optimal place, see #2325 and emscripten PRs will be opened once other stuff lands.
However, the SafeHeap pass must be updated to handle this, or our CI will break in the middle. This PR fixes that, basically making it check if env.DYNAMICTOP_PTR exists, or if not then looking for env.emscripten_get_sbrk_ptr, so that it can handle both.
|
| |
|
|
|
|
|
| |
(which is called DYNAMICTOP_PTR in emscripten) (#2325)
The assumption is that an import env.emscripten_get_sbrk_ptr exists, and we replace the value returned from there with a constant. (We can't do all this in wasm-emscripten-finalize, as it happens before the JS compiler runs, which can add more static allocations; we only know where the sbrk ptr is later in compilation.) This just replaces the import with a function returning the constant; inlining etc. can help more later.
By setting this at compile time we can reduce code size and avoid importing it at runtime, which makes us more compatible with wasi (less special imports).
|
| |
|
| |
This makes the minification pass aware of "wasi_unstable" and "wasi" as well.
|
