Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[NFC] Rename {F32,F64}NearestInt to {F32,F64}Nearest #7089

Merged
merged 157 commits into from
Nov 27, 2024
Merged

Conversation

tlively
Copy link
Member

@tlively tlively commented Nov 19, 2024

Rename the opcode values in wasm-binary.h to better match the names of
the corresponding instructions. This also makes these names match the
scheme used by the rest of the basic unary operations, allowing for more
macro use in the binary reader.

In preparation for using IRBuilder in the binary parser, eagerly create
Functions when parsing the function section so that they are already
created once we parse the code section. IRBuilder will require the
functions to exist when parsing calls so it can figure out what type
each call should have, even when there is a call to a function whose
body has not been parsed yet.

NFC except that some error messages change to include the new empty
functions.
The purpose of the datacount section is to pre-declare how many data
segments there will be so that engines can allocate space for them
and not have to back patch subsequent instructions in the code section
that refer to them. Once we use IRBuilder in the binary parser, we will
have to have the data segments available by the time we parse
instructions that use them, so eagerly construct the data segments when
parsing the datacount section.
The binary parser generally does not know the final names of module
elements when it parses them, or even when it parses instructions that
refer to them, since the name section comes at the end of a binary. The
parser previously kept a list of pointers to locations where each module
element's name would have to be used, then it patched those locations
after parsing the names section to discover the final names.

When the binary parser starts using IRBuilder, the parsed expressions
will be constructed and managed by IRBuilder rather than by the parser
itself. This means that the parser will no longer be able to collect
pointers to places where module element names are used; it won't have
access to the instructions at all.

Since the strategy of collecting locations to patch will no longer work,
switch to a strategy of traversing the module to find and update names
instead. This is generally less efficient because the locations have to
be found before they can be updated, but on the other hand it only
happens when preserving debug info and it is parallelizable anyway.
IRBuilder is a utility for turning arbitrary valid streams of Wasm
instructions into valid Binaryen IR. It is already used in the text
parser, so now use it in the binary parser as well. Since the IRBuilder
API for building each intruction requires only the information that the
binary and text formats include as immediates to that instruction, the
parser is now much simpler than before. In particular, it does not need
to manage a stack of instructions to figure out what the children of
each expression should be; IRBuilder handles this instead.

There are some differences between the IR constructed by IRBuilder and
the IR the binary parser constructed before this change. Most
importantly, IRBuilder generates better multivalue code because it
avoids eagerly breaking up multivalue results into individual components
that might need to be immediately reassembled into a tuple. It also
parses try-delegate more correctly, allowing the delegate to target
arbitrary labels, not just other `try`s. There are also a couple
superficial differences in the generated label and scratch local names.

There are two remaining bugs: First, support for creating DWARF location
spans is missing because IRBuilder does not have an API for that
yet (but source map locations work fine). Second, IRBuilder generates
pops inside nameless blocks in some circumstances involving stacky code.
This is currently an IR validation error, so #6950 will have to be
resolved before this can land.

This change also makes the binary parser significantly slower (by about
50%). The lowest hanging performance fruit seems to be tracking branch
targets in IRBuilder to avoid having to scan for branches when
finalizing blocks.
There were previously two separate code paths for printing function signatures,
one for imported functions and one for declared functions. The only intended
difference was that parameter names were printed for declared functions but not
for imported functions.

Reduce duplication by consolidating the code paths, and add support for printing
names for imported function parameters that have them. Also fix a bug where
empty names were printed as `$` rather than the correct `$""`.
Rather than back-patching names when we get to the names section in the binary
reader, skip ahead to read the names section before anything else so we can use
the final names right away. This is a prerequisite for using IRBuilder in the
binary reader.

The only functional change is that we now allow empty local names. Empty names
are perfectly valid.
CodeFolding previously only worked on blocks that did not produce
values. It worked on Ifs that produced values, but only by accident; the
logic for folding matching tails was not written to support tails
producing concrete values, but it happened to work for Ifs because
subsequent ReFinalize runs fixed all the incorrect types it produced.

Improve the power of the optimization by explicitly handling tails that
produce concrete values for both blocks and ifs. Now that the core logic
handles concrete values correctly, remove the unnecessary ReFinalize
run.
Base automatically changed from binary-ir-builder to main November 27, 2024 05:57
@tlively tlively enabled auto-merge (squash) November 27, 2024 05:59
@tlively tlively merged commit b1c5a00 into main Nov 27, 2024
13 checks passed
@tlively tlively deleted the nearest-rename branch November 27, 2024 06:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants