There is a bug in the string flattening changes that happens when we reuse the
leftmost string as the buffer for the flattened string. In this case the
chacter data pointer for dependent strings converted from ropes is set
incorrectly until we reach the leftmost rope, since we initialize the |pos|
variable to the first character after the contents of the leftmost string. In
the original version of this code we use |str->setNonInlineChars(wholeChars)|
for these. This also results in the lengths of these dependent strings being
wrong since this is caculated based on this pointer. This leads to the
assertion failure.
Differential Revision: https://phabricator.services.mozilla.com/D113306
This is much simpler and lets us tidy up the addProperty code more. It also makes
it easier to change ShapeTable for property maps in the future.
Lookup performance and memory usage appear to be similar for the two versions,
probably because ShapeTable used the same double-hashing algorithm and because
we can purge most ShapeTables on GC.
Differential Revision: https://phabricator.services.mozilla.com/D113089
The next patch will assert when adding duplicate keys to the ShapeTable. This caught
an issue with the intrinsics holder (on a single jsreftest): there's an edge
case where we could add "$ArrayValues" to the intrinsics holder twice.
Differential Revision: https://phabricator.services.mozilla.com/D113088
The callers now know whether we're adding a new property to the shape or just changing
a property, so they can call addProperty directly in the former case. This lets us
simplify putProperty a bit.
Differential Revision: https://phabricator.services.mozilla.com/D113084
As a step towards moving mach commands outside of classes, this converts all
properties into methods so that they can later become top-level helper functions.
Differential Revision: https://phabricator.services.mozilla.com/D112196
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
This commit adds a new testing utility for checking NaN flavors and
uses it for spec tests. The spectest generator uses this when
appropriate, and switches to bitwise equality for all other cases.
The comparison functions for arithmetic/canonical nan's was taken
from wasmtime's spectest runner without deep examination.
Differential Revision: https://phabricator.services.mozilla.com/D112998
WASI doesn't support catching call-stack overflows with
stack-pointer checks, so custom RecursionLimiter is used to directly count entries to certain functions
and report stack overflows.
Differential Revision: https://phabricator.services.mozilla.com/D111813
This bug is an extension of bug 1704467. That bug was triggered when we had a phi with one undefined operand and one OSRValue operand; this bug is triggered if we have a phi with one undefined operand and a second phi operand, which in turn has OSRValue operands. I've updated the testcase to test the broader problem.
It's relatively simple to fix this, but at this point I'm tired of playing whack-a-mole with this code. All of these problems (this bug, bug 1704467, bug 1701208) happen when we try to specialize OSR phis after branch pruning has removed the path from the entry block to the preheader. The cleanest fix, which I probably should have done a while ago, is to just disable OSR phi specialization in this case. It's not clear that it's even useful: for example, in this testcase, which isn't particularly weird, we end up specializing `o1` and `o2` to null because that's the only information we have, which will cause us to immediately bail out and recompile.
After disabling OSR specialization, we can also remove the extra code we added to handle this weird case.
Differential Revision: https://phabricator.services.mozilla.com/D112827
This patch updates tests262, enables the ergnomic brand check tests, and disables those that do not currently pass.
I have opened bugs for the new test cases that are skipped.
Differential Revision: https://phabricator.services.mozilla.com/D113030
MacroAssembler methods PushRegsInMask, storeRegsInMask, PopRegsInMask and
PopRegsInMaskIgnore create code to save/restore arbitrary subsets of the
registers in memory. Unfortunately logic which computes the size of this area
is decoupled from those routines and is not documented as being dependent on
them. This also means the format must be the same for all targets, which may
not be optimal in future when we come to save/restore SIMD registers on more
targets.
This patch introduces a new method, MacroAssembler::PushRegsInMaskSizeInBytes,
to calculate that size independently on a per-platform basis. Ad-hoc
computations of the size are replaced by a call to this method. On
x86_{32,64} and arm{32,64}, the method is used in assertions to crosscheck
the actual used size in PushRegsInMask, storeRegsInMask and
PopRegsInMaskIgnore.
The inferred invariants have been recorded in comments. There is no change to
the generated code.
Differential Revision: https://phabricator.services.mozilla.com/D112533
When changing a dictionary property, we have to generate a new shape for the
object (last property shape) and we can then mutate the property in place.
This removes the extra shape allocation for the mutated property.
This reverts the change in bug 703157: the issue fixed there no longer applies.
`replaceWithNewEquivalentShape` is then only used for `generateOwnShape`, to generate
a new shape for the last property, so we can inline it into `generateOwnShape` and
simplify the code a bit.
Differential Revision: https://phabricator.services.mozilla.com/D112907
Shifts and rotates may require a variable RHS to be in a specific
register. We can express this generically by passing an rhs-popper
function to the emitter.
(64-bit rotates are additionally complicated by requiring a temp, and
are not translated in this patch.)
Differential Revision: https://phabricator.services.mozilla.com/D109610
Popcount may need a temp; whether it does depends on both the platform
and the CPU. A custom temp allocator function can be passed to the
emitter and used generically.
Differential Revision: https://phabricator.services.mozilla.com/D109609
Translate the existing emitters that have simple register use patterns
(no custom pops, temps, widens, or narrows) into the new templated
style.
Differential Revision: https://phabricator.services.mozilla.com/D107798
The templates that were introduced for SIMD are promoted from
emitVectorWhatever to emitWhatever, so that they can be used more
generally. They are also moved away from SIMD-specific code to a more
generic place in the compiler.
Some type-specific names for which type information is otherwise
available though a parameter type are changed to become type-agnostic
(popConstT -> popConst for example), this will aid further template
use.
Differential Revision: https://phabricator.services.mozilla.com/D109608
We do not allow `new` in self-hosting, except in these special cases. We can
avoid `new` in these remaining cases as well by using std_Object_create. The
created objects are internal to self-hosting algorithms and are never exposed
to user scripts.
Differential Revision: https://phabricator.services.mozilla.com/D112435
Shifts and rotates may require a variable RHS to be in a specific
register. We can express this generically by passing an rhs-popper
function to the emitter.
(64-bit rotates are additionally complicated by requiring a temp, and
are not translated in this patch.)
Differential Revision: https://phabricator.services.mozilla.com/D109610
Popcount may need a temp; whether it does depends on both the platform
and the CPU. A custom temp allocator function can be passed to the
emitter and used generically.
Differential Revision: https://phabricator.services.mozilla.com/D109609
Translate the existing emitters that have simple register use patterns
(no custom pops, temps, widens, or narrows) into the new templated
style.
Differential Revision: https://phabricator.services.mozilla.com/D107798
The templates that were introduced for SIMD are promoted from
emitVectorWhatever to emitWhatever, so that they can be used more
generally. They are also moved away from SIMD-specific code to a more
generic place in the compiler.
Some type-specific names for which type information is otherwise
available though a parameter type are changed to become type-agnostic
(popConstT -> popConst for example), this will aid further template
use.
Differential Revision: https://phabricator.services.mozilla.com/D109608
Andi-Bogdan Postelnicu
Jon Coppeard
Jan de Mooij
Ashita
Butkovits Atila
mr.robot
Alex Lopez
Tom Schuster
Narcis Beleuzu
Ryan Hunt
Valentin Gosu
Dmitry Bezhetskov
Chris Fallin
Lars T Hansen
Iain Ireland
Matthew Gaudet
Yoshi Cheng-Hao Huang
Julian Seward
Garima
Ted Campbell
Brindusan Cristian