Largely combinations of i32.const and local.get.
This shaves off at most single-digit% number of instructions from
dispatch, which translates to at most ~10% reduced dispatch time.
Across most benchmarks, this gains around ~5% perf increase.
This commit adds a register allocator, with 8 available "register"
slots.
In testing with various random blobs, this moves anywhere from 30% to
74% of value accesses into predefined slots, and is about a ~20% perf
increase end-to-end.
To actually make this usable, a few structural changes were also made:
- we no longer do one instruction per interpret call
- trapping is an (unlikely) exit condition
- the label and frame stacks are replaced with linked lists with a huge
node cache size, as we only need to touch the last element and
push/pop is very frequent.
This is largely unused (only in wasm.cpp)
A future reimplementation can bring it back as a separate interpreter
class that embeds the current bytecode interpreter.
...for the first byte.
This function only really needs to read a single byte at that point, so
read_until_filled() is useless and read_value<u8> is functionally
equivalent to just a read.
This showed up hot in a wasm parse benchmark.
The average wasm function rarely goes over these bounds for the labels
(32 nested control structures), and 8 frames is just enough to clear
most initialization code/start section without allocating anything.
These are quite bottlenecky in wasm, the next commit will try to make
use of this by calling them directly instead of doing a vcall, and
having them inlineable helps the compiler a bit.
If the address is already aligned properly, just read a T from it;
otherwise copy it to a local aligned array. This was a bottleneck on
memory-heavy benchmarks.
This is an editoral change from the fetch spec. Since we already defined
the stream before it being used this only re-numbers the spec steps.
It also corrects a minor typo ('followings' to 'following') which was
corrected in the same editoral spec change.
- Omit calcs that are resolved to `0px` from the serialized value
- Allow CSV to be the 'Z' component in interpolated value.
- Allow calcs with mixed percentages in the first two arguments.
To achieve the third item above the concept of a "special" value parsing
context has been added - this will also be useful for instance for
different arguments of color functions having different contexts.
Gains us 23 WPT tests
We were failing to discriminate between DOM removals happening to SVG
elements cloned as part of an SVG use element instantiation.
When a "use source" element is removed, all clones of that source must
be updated to reflect the change. But when a "use clone" element is
removed, that's fine.
This was causing the surprising disappearance of use element subtrees,
seen for example on https://cal.com/
This lets you access closed shadow roots from JavaScript, even though
they're not normally accessible to JavaScript. This can be used to poke
into UA shadow roots in tests.
Fixes external CSS being blocked on https://beatsaver.com/, where they
have a `style-src` directive set to `'self' 'nonce-[value]'`
Relates to #5643, but does not make the website load.
Technically, env() should not be an ASF. (😱) This is why some tests
still fail - env() as specced is expected to have its syntax checked
fully at parse-time, whereas ASFs are not properly syntax-checked until
later. However, I think this approach was worth doing for a few reasons:
- env() behaves like an ASF otherwise. (It is replaced with a set of
arbitrary component-values that are not known until computed-value
time.)
- env() was defined before the ASF concept existed, so I strongly
suspect it will be updated in the future to match that definition,
with a couple of adjustments. (eg, env() is allowed in some extra
places compared to var() and attr().)
- This was much quicker and easier to implement (under 3 hours in total)
compared to the greater amount of work to implement a whole separate
system just for env().
- Most of these tests are marked tentative, and the spec definition of
env() is still somewhat in flux, so failing some is not a huge deal.
If in the future I turn out to be wrong on this, we can convert it to
its own special thing.
