Add a mozilla::intl::DateIntervalFormat class, with two methods:
- TryFormatCalendar
- TryFormatDateTime
and a mozilla::intl::AutoFormattedDateInterval class, which is a RAII
class calling udtitvfmt_openResult and udtitvfmt_closeResult for
DateIntervalFormat operations.
Differential Revision: https://phabricator.services.mozilla.com/D125642
For addressing expressions we want to special-case zero. Now that
pointers can be 64-bit values, recognize also 64-bit zeroes.
Differential Revision: https://phabricator.services.mozilla.com/D128377
The isMem32 predicate assumes that there's a memory present (and this
is the right thing), but sometimes we must call isMem32 before we've
checked for the presence of a memory, this is a consequence of the
structure of the compiler. Specifically, we must determine the
appropriate signature for a bulk memory instance call before reading
the opcode, and the signature depends on the memory type, yet it's the
opcode reading that checks for the presence of the memory and throws
if one is not present.
Introduce a new predicate for these situations and use it as
appropriate. It is safe to assume mem32 if a memory is not present,
as the presence of a memory will be checked properly subsequently.
The isMem64 predicate is not affected as it is not used in these
situations.
Only Ion is affected, baseline already has the necessary guard in all
the required situations.
The missing test cases were an oversight - I introduced tests like
these for the memory instructions previously, but I forgot wait and
notify.
Differential Revision: https://phabricator.services.mozilla.com/D128869
In general, these test cases may allocate a lot of memory and should be allowed
to OOM, cf the test in ../large-memory.js
Differential Revision: https://phabricator.services.mozilla.com/D128852
It's slightly annoying that we now have to store a tracer rather than just a
bool, but it's necessary because these container methods don't have any context
we can get it from.
Differential Revision: https://phabricator.services.mozilla.com/D128861
Making this change meant fixing WeakCached things that supplied their own sweep
method at the same time because the custom sweep method would no longer be
called. This dragged in a bunch of other changes but it's all along the same
lines as the previous patches.
Depends on D128859
Differential Revision: https://phabricator.services.mozilla.com/D128860
This refactors some of the code to remove indirection from Zone methods to
WeakMapBase where it's simpler just to implement the method on Zone.
Differential Revision: https://phabricator.services.mozilla.com/D128352
Both `initFromTemplateObject()` methods are always returning `true`, so we might
as well change the return type to `void`.
Depends on D128765
Differential Revision: https://phabricator.services.mozilla.com/D128766
The other caller to `visitObjectGuard()` was removed when unboxed objects were
removed, so we can move the function back into `visitGuardShape()`.
Depends on D128764
Differential Revision: https://phabricator.services.mozilla.com/D128765
`ArgumentsReplacer::run()` ignores any resume points, so we can directly use
`MDefinitionIterator` to iterate over all definitions.
Differential Revision: https://phabricator.services.mozilla.com/D128764
`MLoadElementHole::needsHoleCheck` is never set to `false`.
Drive-by change:
- Remove two method declarations without definitions.
Differential Revision: https://phabricator.services.mozilla.com/D128762
We added a speculation barrier after calls into C++ from ICs (bug 1444473).
In hindsight, it seems we were overly cautious with the calls for megamorhic property
gets because the slot number comes from the shape's property map. This makes it very
different from the typical Spectre v1 attack with a user-controlled index into a
(typed) array, where the bounds check then gets delayed/speculated.
Furthermore, this happens in C++ code that's not user-controlled and it'd need a
large speculation window that includes the return to JIT code. There we have
additional mitigations when unboxing the returned Value.
This barrier has a large impact on performance: on a simple micro-benchmark it
increases our numbers from 75 ms to 170 ms on Linux x64, more than a 2x slowdown
for one of our hottest code paths. This makes it hard to justify keeping it.
Differential Revision: https://phabricator.services.mozilla.com/D128744
Most of the time we only sweep things in zones that are being swept, but there
are a couple of places where this isn't true. This fixes the sweeping tracer to
take account of that.
Differential Revision: https://phabricator.services.mozilla.com/D128758
On mips64, when 64-bit GPRs carrying 32-bit values, the upper bits are the sign extension
of the lower bits, and 32-bit instructions will check this invariant.
But on x64 and arm64, the upper bits are zero, and 32-bit instructions don't care about
the upper 32 bits of the inputs.
So when some 32-bit operations like mul32 are used, we should keep the inputs sign-extended.
And if we want a zero-extended 32-bit value, like for some bitwise operations, an explicit
zero-extension is needed.
Differential Revision: https://phabricator.services.mozilla.com/D128564
...property is true". r=jonco
Currently unused, but an example usage would be to enforce a rule where you're supposed to annotate functions as safe, meaning they cannot invoke some function F. We would set a bit for annotated functions. Then if there is any route to F where that bit is set, we know we have a problem. (The currently intended use is a bit more complicated.)
Differential Revision: https://phabricator.services.mozilla.com/D46545
If we bail out of Warp based on the result of an inlined call to Math.random and then resume prior to the call, the RNG state will be updated and we won't generate the same value when we resume in baseline. This can lead to repeated bailouts and in extreme cases skew the distribution of random numbers. The most straightforward fix is to make `MRandom` effectful, with a new alias set representing the RNG state. Since MRandom already isn't movable, I think this doesn't change much; there are only a few ops with `AliasSet::Load(AliasSet::Any)` that can no longer be moved past `MRandom`.
Differential Revision: https://phabricator.services.mozilla.com/D128654
We use the 'needsSweep' method name for two separate things. We use it in
WeakCache to check whether a cache needs to be swept at all, i.e. whether it is
not empty. We also use it in the GCPolicy trait as a method to sweep something.
GCHashMap/Set/GCVector implement it for the former reason, and so if we attempt
to use one for something that will be swept with GCPolicy it won't work.
I was going to rename the WeakCache method later anyway (because it's clearer
just to provide an empty() method) but I hadn't realised this collision was
going to happen. The patch in bug 1736021 causes a GCVector to be swept via
GCPolicy which calls the existing needsSweep() method which doesn't sweep at
all. The fix is to provide a version that does.
This will itself go away soon and be replaced with traceWeak(), but we'll fix
this problem first.
Differential Revision: https://phabricator.services.mozilla.com/D128740
Lars T Hansen
Yoshi Cheng-Hao Huang
Tooru Fujisawa
Csoregi Natalia
Steve Fink
Jon Coppeard
Jan de Mooij
Zhao Jiazhong
André Bargull
Paul Bone
Gerald Squelart
Cristian Tuns
Iain Ireland