This also makes `Utf8View::trim` significantly faster, since most
strings start and end with ASCII.
(cherry picked from commit 7f3269fb025051c3eb2794b15e785b85b0ce37f3)
And let's at least try to pre-allocate an appropriate amount of
buffer space in the builder instead of appending and growing one
code point at a time.
(cherry picked from commit b6e28ff80779520ccb49e6c15ae1866bbc8713a7)
Also updates a LibWeb text test that used to report the wrong line
number.
(cherry picked from commit 02b50d463b174e5d525c7ab8ce8dd173d550de28;
amended to exclude LineTrackingLexer from KERNEL, since that now use
make<>)
This is necessary for the next commit (and might even help performance
in some very weird cases).
(cherry picked from commit e5f87eb12bdad9dfbf8a825461ac17fdb8457f50;
amended to add a missing include of StdLibExtras.h for move())
You can now build with STYLE_INVALIDATION_DEBUG and get a debug stream
of reasons why style invalidations are happening and where.
I've rewritten this code many times, so instead of throwing it away once
again, I figured we should at least have it behind a flag.
(cherry picked from commit ddbfac38b0074819470766846fca08fd78630eb0;
minorly amended for conflicts in AK/Debug.h.in and
Meta/CMake/all_the_debug_macros.cmake due to us having more debug
macros. Also, downstream got alphabetical order for
STYLE_INVALIDATION_DEBUG wrong.)
(cherry picked from commit 7a17c654d293c4afaf3086dc94e8cd4bceac48b1;
amended to resolve minor conflict in TestUtf16.cpp due to us not
(yet?) having `TEST_CASE(null_view)`. Also amended to make the new
method not call simdutf -- it's now also inefficient, but at least
the inefficient code is now only in one place instead of in several)
This ports the same optimization which was made in
1a46d8df5fc81eb2c320d5c8a5597285d3d8fb3a to this function as well.
(cherry picked from commit 1e8cc97b731871409316c121e637c32806135122)
This takes a byte sequence and converts it to a UTF-8 string with the
replacement character.
(cherry picked from commit 033ea0e7fb0f72338ae95aa0413da838206440bb)
Only take this fast path if the power actually fits in an integer type.
Also, use 64-bit integers in all cases so that the fast path can be
taken more often.
This makes it a compile error to use is<T>() where the input and output
types are known to be the same at compile time.
(cherry picked from commit 82a63e350cb9a67cbd3aa659d909ae9e6599e93f)
C++ will jovially select the implicit conversion operator, even if it's
complete bogus, such as for unknown-size types or non-destructible
types. Therefore, all such conversions (which incur a copy) must
(unfortunately) be explicit so that non-copyable types continue to work.
For some reason, Clang wants AK to work with exceptions enabled so much
that it produces a very annoying warning complaining about the absence
of (completely useless in our setup) unhandled_exception method in
promise type for every coroutine declared. We work around this during
build by suppressing -Wcoroutine-missing-unhandled-exception in
Meta/CMake/common_compile_options.cmake. However, the flag is only added
if build is using Clang. If one builds coroutine code with GCC but still
uses clangd, clangd, obviously, doesn't pick up warning suppression and
annoys user with a squiggly yellow line under each coroutine function
declaration.
This fixes cases where fuzzy matching would return a better score for
a different pattern than a needle perfectly matching the haystack.
As an example, when searching for "fire" in emojis, "Fire Engine" would
have scored 168, while "Fire" was giving only 160.
This patch makes the latter have the best possible score.
Takes
(cd Tests/LibGfx; ../../Build/lagom/bin/BenchmarkPNG)
from 59ms to 32ms on my system.
Adds AK::SIMD::bitselect() (modeled after the wasm SIMD equivalent),
and AK::SIMD::abs() implemented on top of it.
No behavior change.
Unroll the first byte as a fast path, and remove a branch. This speeds
up the instantiation of spidermonkey by 10ms.
(cherry picked from commit a6ebd100ecd9ed633e290153f61466362e63b73a)
`swizzle` had the wrong operands, and the vector masking boolean logic
was incorrect in the internal `shuffle_or_0` implementation. `shuffle`
was previously implemented as a dynamic swizzle, when it uses an
immediate operand for lane indices in the spec.
(cherry picked from commit 9cc3e7d32d150dd30d683c1a8cf0bd59676f14ab)
It turns out we cannot use function multi-versioning with "sha" feature
or even just plain ifunc resolvers without preprocessor guards. So,
instead of feeding ifdef-soup monster, we just use static member
function pointer.
Moving the kernel into the SHA1 class makes it possible to not pass
class members as parameters to it. This, however, requires us to
disambiguate different target "clones" of the kernel using some kind
of template.
The helper doesn't use __builtin_cpu_supports (and instead makes raw
cpuid calls) because of three reasons:
- __builtin_cpu_supports only works on x86_64, so its usage need to be
guarded with the preprocessor similarly to the current code.
Moreover, we will have to use custom mechanisms to detect features on
ARM, since there isn't such thing as cpuid there (and __builtin_cpu_*
are not provided).
- __builtin_cpu_supports doesn't support "sha" feature on all targeted
toolchains currently.
- And, of course, NIH.
This necessitates marking bit_cast as ALWAYS_INLINE since emitting it as
a function call there will create an unnecessary potential SSE
registers -> plain registers/memory round-trip.
This warning is triggered when one accepts or returns vectors from a
function (that is not marked with [[gnu::target(...)]]) which would have
been otherwise passed in register if the current translation unit had
been compiled with more permissive flags wrt instruction selection (i.
e. if one adds -mavx2 to cmdline). This will never be a problem for us
since we (a) never use different instruction selection options across
ABI boundaries; (b) most of the affected functions are actually
TU-local.
Moreover, even if we somehow properly annotated all of the SIMD helpers,
calling them across ABI (or target) boundaries would still be very
dangerous because of inconsistent and bogus handling of
[[gnu::target(...)]] across compilers. See
https://github.com/llvm/llvm-project/issues/64706 and
https://www.reddit.com/r/cpp/comments/17qowl2/comment/k8j2odi .
It seems that libexecinfo was broken on musl (and possibly other libcs)
for quite a while now (resulting in a segfault, or returning 0 frames).
Hence, we shouldn't include it there because it doesn't provide any
added functionality.
