This now uses `if constexpr (...)` which is a lot more readable, and still
compiles to almost no assembly instructions, as expected.
Floating point casting assert when casting an integer that's too large to be
represented exactly as a floating point (e.g. UINT64_MAX to double, since double
have less than 64 bytes of mantissa), or when casting a double that's too large
to be represented in a float.
Differential Revision: https://phabricator.services.mozilla.com/D167955
This now uses `if constexpr (...)` which is a lot more readable, and still
compiles to almost no assembly instructions, as expected.
Floating point casting assert when casting an integer that's too large to be
represented exactly as a floating point (e.g. UINT64_MAX to double, since double
have less than 64 bytes of mantissa), or when casting a double that's too large
to be represented in a float.
Differential Revision: https://phabricator.services.mozilla.com/D167955
C++20 deprecated decrement/increment of object of volatile-qualified types, e.g. v++.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1152r3.html
mfbt/SHA1.cpp:400:9 [-Wdeprecated-volatile] compound assignment to object of volatile-qualified type 'volatile unsigned int' is deprecated
mfbt/SHA1.cpp:401:9 [-Wdeprecated-volatile] compound assignment to object of volatile-qualified type 'volatile unsigned int' is deprecated
mfbt/SHA1.cpp:402:9 [-Wdeprecated-volatile] compound assignment to object of volatile-qualified type 'volatile unsigned int' is deprecated
mfbt/SHA1.cpp:403:9 [-Wdeprecated-volatile] compound assignment to object of volatile-qualified type 'volatile unsigned int' is deprecated
mfbt/SHA1.cpp:404:9 [-Wdeprecated-volatile] compound assignment to object of volatile-qualified type 'volatile unsigned int' is deprecated
shaCompress() has a comment emphasizing the importance of the X array being volatile. I verified that changing `XH(0) += A` to `XH(0) = XH(0) + A` generates the same -S assembly code (for clang -O2 on Apple Silicon).
Whether this comment about the volatile code generated by gcc 3.4.3 -O3 in 2012 is still relevant for clang 15 -O2 in 2023 is a different question.
Differential Revision: https://phabricator.services.mozilla.com/D165268
The annotations added in bug 1770158 only covered `StringToDouble`,
however as noted in the comments in that file, that isn't sufficient for
accurately parsing floating point numbers. This patch extends the
annotations to the single-precision floating point numbers as well and
will be used in the next part to clean up the implementation of
`nsTString::ToDouble`.
Differential Revision: https://phabricator.services.mozilla.com/D148304
It's unclear to me when they were disabled, but we do want to enable
these as otherwise there's no way to catch bindgen issues that can end
up in subtle bugs at best, or memory corruption at worst.
Differential Revision: https://phabricator.services.mozilla.com/D162997
It is possible to specify full names for capabilities when using the clang
thread-safety analysis which will be used in error messages. We should use that
form of the attribute rather than the legacy lockable attribute.
Differential Revision: https://phabricator.services.mozilla.com/D160531
Some profiling of tcampbell's React benchmark [1] shows 6.1 million calls to
js::frontend::GeneralTokenStreamChars<..>::getFullAsciiCodePoint, using 110.57
million instructions (x86_64). That comes out to only 18 insns per call,
which suggests the method is a good candidate for inlining, but it isn't
inlined.
Merely parking an inline annotation on it doesn't help much, because it gets
inlined into js::frontend::TokenStreamSpecific<..>::getCodePoint, but that
isn't inlined into *its* caller(s), so the 6.1 million calls move to
::getCodePoint instead.
This patch requests inlining for both ::getFullAsciiCodePoint and
::getCodePoint and adds some MOZ_NEVER_INLINE annotations to ensure that cold
paths *don't* get inlined into these two, to reduce code bloat and avoid
excessive register pressure.
IsAscii functions in mfbt/TextUtils.h have been marked inline as a precaution;
this probably isn't necessary.
Run time with config [2] is reduced from 0.390 seconds to 0.379 seconds
(2.8% speedup, best of 50 runs), and from 0.402 to 0.396 seconds
(median of 50 runs).
Instruction count falls from 3511.8 million to 3395.8 million, and the number
of data accesses from 1563.7 million to 1487.4 million -- a 4.8% reduction
that is probably caused by avoidance of save/restore sequences in the inlined
fns.
[1] https://github.com/mozilla-spidermonkey/matrix-react-bench
[2] Fedora 35, x86_64, Intel Core i5 1135G7 at 4 ish GHz
configure: --disable-debug --enable-optimize="-g -O2"
run: --no-threads
Differential Revision: https://phabricator.services.mozilla.com/D159500
The only uses of this method were removed in Part 1, meaning that it can
now be removed. Support for this method adds a significant amount of
complexity to `BufferList` and IPC serialization.
Differential Revision: https://phabricator.services.mozilla.com/D154439
Deletion of mutation observers from a list resulted in O(n^2) behavior and could lead to massive freezes.
This is resolved by using a LinkedList instead, reducing complexity to O(n).
A safely iterable doubly linked list was implemented based on `mozilla::DoublyLinkedList`,
allowing to insert and remove elements while iterating the list.
Due to the nature of `mozilla::DoublyLinkedList`, every Mutation Observer now inherits `mozilla::DoublyLinkedListElement<T>`.
This implies that a Mutation Observer can only be part of one DoublyLinkedList.
This conflicts with some Mutation Observers, which are being added to multiple `nsINode`s.
To continue supporting this, new MutationObserver base classes `nsMultiMutationObserver` and `nsStubMultiMutationObserver` are introduced,
which create `MutationObserverWrapper` objects each time they are added to a `nsINode`.
The wrapper objects forward every call to the actual observer.
Differential Revision: https://phabricator.services.mozilla.com/D157031
The next patch is creating a cache which is capable of looking up different kind
of string types. However, each string type need some contextual information to
be able to compare them against each others, which adds complexity to the lookup
type. In addition, the keys are of only one string type, and therefore we try to
avoid storing this context as part of each key, but instead provide it with the
contextual information coming with the Lookup type.
Therefore, when we want to insert a key, which might already be present, using
`put`. We have to provide a `aLookup` argument which knows how to compare keys.
This also make the interface similar to `putNew` which already has the
distinctions between the `Lookup` argument and the `KeyInput` argument.
Differential Revision: https://phabricator.services.mozilla.com/D154512
All JSONWriteFuncs are effectively final, this patch enforces that, hopefully
helping the compiler to de-virtualize some calls.
Differential Revision: https://phabricator.services.mozilla.com/D154619
mWriter is now a reference, and the ownership is optional through a separate
member variable that could stay null.
User can now choose to keep the JSONWriteFunc on their stack, which saves a
heap allocation, and makes it easier to access the concrete JSONWriteFunc
implementation directly (instead of through WriteFunc()).
Differential Revision: https://phabricator.services.mozilla.com/D154617
mWriter is never null (and lots of calls just dereference it without checking),
so we may as well enforce it:
- The constructor MOZ_RELEASE_ASSERTs that it's not null.
- The accessor WriteFunc() returns a reference instead of a scary raw pointer.
(Note that we can't make mWriter a NotNull<...>, because the next patch will
give the option to keep that owning pointer null.)
Differential Revision: https://phabricator.services.mozilla.com/D154616
All JSONWriteFuncs are effectively final, this patch enforces that, hopefully
helping the compiler to de-virtualize some calls.
Depends on D154618
Differential Revision: https://phabricator.services.mozilla.com/D154619
mWriter is now a reference, and the ownership is optional through a separate
member variable that could stay null.
User can now choose to keep the JSONWriteFunc on their stack, which saves a
heap allocation, and makes it easier to access the concrete JSONWriteFunc
implementation directly (instead of through WriteFunc()).
Depends on D154616
Differential Revision: https://phabricator.services.mozilla.com/D154617
mWriter is never null (and lots of calls just dereference it without checking),
so we may as well enforce it:
- The constructor MOZ_RELEASE_ASSERTs that it's not null.
- The accessor WriteFunc() returns a reference instead of a scary raw pointer.
(Note that we can't make mWriter a NotNull<...>, because the next patch will
give the option to keep that owning pointer null.)
Differential Revision: https://phabricator.services.mozilla.com/D154616
Andi-Bogdan Postelnicu
Norisz Fay
Kelsey Gilbert
Paul Adenot
Stanca Serban
Olli Pettay
Csoregi Natalia
Chris Peterson
Marian-Vasile Laza
Ryan VanderMeulen
Nika Layzell
Emilio Cobos Álvarez
James Teh
Julian Seward
Peter Van der Beken
Sandor Molnar
Jan-Niklas Jaeschke
Nicolas B. Pierron
Nick Alexander
Gerald Squelart
André Bargull
Iulian Moraru
Steve Fink
Cristian Tuns
Emily McDonough
Fabrice Desré
Andreea Pavel