Repository navigation
Aarch64 be fix - #1066
Aarch64 be fix#1066zeldin wants to merge 2 commits into
Conversation
There was a problem hiding this comment.
🔵 Needs a closer look
Unavailable SLJIT revisions and source prevent verification of the big-endian SIMD contracts, requiring human review and native ARM64 BE/LE validation across all three widths.
No open issues 🎉
What changed in this PR
Fixes big-endian AArch64 SIMD handling in PCRE2’s JIT character-search optimizations while preserving the little-endian paths.
Changes:
- Selects endian-appropriate instructions for packing comparison results and locating the first match.
- Reverses masking shifts for big-endian match ordering.
- Adjusts vector lane moves and shifts used by character-pair searches.
| File | Description |
|---|---|
src/pcre2_jit_simd_inc.h |
Adds endian-aware AArch64 SIMD operations for character, required-character, and character-pair searches. |
Review effort: Balanced
|
Wow, this isn't even big endian armv7. Are there actually big endian aarch64/armv8 systems? Let me know how common they are. Is this purely theoretical? Is there a single Linux distro with an arch triplet for this? The alternative to fixing it, is to add #error to reject it at build time. (Potentially all jit builds should do that - validate endianness. Only a tiny number are bi-endian, a mega rare subset of the already rare big endians.) |
|
All 64-bit Cortex-A cores from ARM are bi-endian. Several systems with such cores can boot a big-endian kernel "on the metal", such as Traverse Ten64 and Raspberry Pi 3 (see https://github.com/zeldin/linux-1/releases/tag/pi3be_v0.6 for an sdcard image). Cross-endian guests with KVM are also widely available. Yes, Gentoo Linux has a triplet for big endian aarch64, |
|
If it's just Gentoo, that's a bit revealing (ie perhaps no-one is distributing pre-built software for this triplet?). I notice that release you linked to is yours, so I'm curious to know if this is a project where you know of other Aarch64 BE users. If we do need to support Aarch64 BE, then it should be added to our CI if possible; ideally using the CI job which builds using a cross-compiler and then runs the test under qemu (we have another, slower build job that runs compiler under qemu as well). |
| instruction = 0x0f0c8400 | (data_ind << 5) | data_ind; | ||
| #else | ||
| /* SHRN2 */ | ||
| instruction = 0x4f0c8400 | (data_ind << 5) | data_ind; |
There was a problem hiding this comment.
This change is repeated many times. We should introduce a const for SHRN2.
There was a problem hiding this comment.
Good point. And of course also for SHRN, CMEQ, ORR, INS, SHL and USHR which were already repeated before.
Nope. But then again I don't know of other Aarch64 LE users either, so not much of a datapoint. 😸 My main interrest in ARM is as an up-to-date performant hardware capable of running BE code.
If you are cross-compiling for little endian ARM64 already you should be able to use the same cross-compiler; just add |
Looks like there is at least Alpine builds too, if you don't like Gentoo. 😁 |
This PR fixes the ARM64 JIT which was broken when running in big endian mode.
With these changes
pcre2_jit_testpasses on hardware (Cortex-A720, ARMv9.2-A) in both big and little endian mode.Note that a bump of the
deps/sljitsubmodule is included as that dependency also had issues with big endian ARM64 before. The bump only pulls in the related ARM fixes; there are no other upstreams changes which were not already in PCRE2.