GH-50503: [Parquet] Remove SVE128 unpack

[AntoinePrv]

Rationale for this change

The SVE128 code path has conflict with the SVE256 that we do not yet manage properly.

• There was first the ODR violation in [C++] Bump xsimd to 14.2.0 #49921
• Now it seems that there may also be an issue with LTO

Anyhow, after we fixed the inlining issue in Neon, the SVE128 had no clear advantages over Neon as expected, os this was due to be removed anyways.

What changes are included in this PR?

Remove SVE128 unpack

Are these changes tested?

In CI.

Are there any user-facing changes?

No

• GitHub Issue: [Python][C++] 25.0.0 aarch64 wheel: deterministic dictionary-decode failure on Neoverse V1 / AWS Graviton3 (SIGSEGV via iter_batches; ArrowInvalid single-threaded); N1/V2 unaffected; 24.0.0 OK #50503

[github-actions]

⚠️ GitHub issue #50503 has been automatically assigned in GitHub to PR creator.

[raulcd]

@github-actions crossbow submit wheel-manylinux-2-28-cp313-cp313-arm64

[github-actions]

Revision: 84f8209

Submitted crossbow builds: ursacomputing/crossbow @ actions-8af012a39a

Task	Status
wheel-manylinux-2-28-cp313-cp313-arm64

[AntoinePrv]

@github-actions crossbow submit wheel-manylinux-2-28-cp313-cp313-arm64

[github-actions]

Revision: 3458a70

Submitted crossbow builds: ursacomputing/crossbow @ actions-b71ab30610

Task	Status
wheel-manylinux-2-28-cp313-cp313-arm64

[raulcd]

The wheel can be downloaded from the summary page artifacts on the job:
https://github.com/ursacomputing/crossbow/actions/runs/29994419195

[pitrou]

Can we try to understand what happens? For example look for symbols with sve in them but no sve128 or sve256.

[AntoinePrv]

The best hypothesis I have goes as follows (this was heavily AI assisted):

We had a similar problem with the ODR violation, but the cause is different here (latest xsimd has the ODR fix).
The issue arise during LTO where the fags -msve-vector-bits=128 and -msve-vector-bits=256 get conflated, resulting in the 256 version making 128 bits assumptions.
The supporting evidence is the presence of ptrue p7.b, vl16 in unpack_sve256: this sets a predicate (all true since we don't use them) only to 16 bytes (128 bits).

While there is some uncertainty in this diagnosis, the presence of both sve128 and sve256 is an extremely likely enabler of the issue. Given I had plan to remove the SVE128 because it did not bring much over Neon, landing this fix has no drawbacks.

[Copilot]

Pull request overview

Removes the SVE128-specific bit-unpacking implementation and associated runtime-dispatch hooks in Arrow C++’s bpacking utility to avoid conflicts with SVE256 (ODR/LTO concerns) and to simplify the SIMD surface area for Parquet decode-related paths.

Changes:

• Removed SVE128 from bpacking dynamic dispatch target list.
• Deleted the SVE128 “128_alt” implementation and removed its build wiring.
• Dropped SVE128-specific unit test and benchmark coverage.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
cpp/src/arrow/util/bpacking.cc	Removes SVE128 from runtime dispatch targets for unpack.
cpp/src/arrow/util/bpacking_test.cc	Removes the SVE128-specific unpack test.
cpp/src/arrow/util/bpacking_simd_internal.h	Removes SVE128 “ALT” unpack declarations/exports.
cpp/src/arrow/util/bpacking_simd_128_alt.cc	Deletes the SVE128 unpack implementation translation unit.
cpp/src/arrow/util/bpacking_benchmark.cc	Removes the SVE128 unpack benchmark.
cpp/src/arrow/CMakeLists.txt	Stops building the SVE128 unpack source file for Arrow util sources.

[raulcd]

should we try building a wheel without LTO and validate?

[AntoinePrv]

should we try building a wheel without LTO and validate?

We can, though it would be a worse fix IMHO.

[pitrou]

The best hypothesis I have goes as follows (this was heavily AI assisted):

We had a similar problem with the ODR violation, but the cause is different here (latest xsimd has the ODR fix). The issue arise during LTO where the fags -msve-vector-bits=128 and -msve-vector-bits=256 get conflated, resulting in the 256 version making 128 bits assumptions.

We should find out why. Can we enable CMAKE_VERBOSE_MAKEFILE on the manylinux build to see all the compiler options for each file? Normally only one -msve-vector-bits is passed for each compilation unit.

[pitrou]

Looking at the original build logs, bpacking_simd_128.cc is compiled inside a unity build compilation unit, which doesn't seem right. It should be compiled independently, just like bpacking_simd_256.cc.

Edit: my bad, it's for NEON.

[pitrou]

Ok, I think the issue is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121412 .

And specifically:

That said, -fno-lto for "mismatched" TUs is the workaroud that, unfortunately, has to be applied on the users side at this point.

[pitrou]

#50618 removes LTO for SVE-enabled translation units and works fine as per @cyb70289

Let's see whether the benchmarks are affected.

[raulcd]

@ursabot please benchmark

[rok]

Benchmark runs are scheduled for commit 3458a70. Watch https://buildkite.com/apache-arrow and https://conbench.arrow-dev.org for updates. A comment will be posted here when the runs are complete.

[AntoinePrv]

Do we have SVE benchmarks?

[pitrou]

Everything that relies on bit-unpacking, i.e. some Parquet reading benchmarks.

[conbench-apache-arrow]

Thanks for your patience. Conbench analyzed the 4 benchmarking runs that have been run so far on PR commit 3458a70.

There were 4 benchmark results indicating a performance regression:

• Pull Request Run on test-mac-arm at 2026-07-24 15:06:52Z
  • BM_UnpackUint16 (C++) with params=DynamicAligned/8/512, source=cpp-micro, suite=arrow-bpacking-benchmark
  • BM_UnpackUint16 (C++) with params=DynamicUnaligned/8/512, source=cpp-micro, suite=arrow-bpacking-benchmark
• and 2 more (see the report linked below)

The full Conbench report has more details.

[raulcd]

The regression for mac-arm seems to be quite significant.

[rok]

The regression for mac-arm seems to be quite significant.

It appears similar regression occurs occasionally. I'll restart the benchmark.

[rok]

@ursabot please benchmark

[rok]

Commit 3458a70 already has scheduled benchmark runs.

[rok]

@AntoinePrv could you push an empty commit so conbench can be started again? (It allows only one benchmark run per commit).

[AntoinePrv]

@ursabot please benchmark

[rok]

Benchmark runs are scheduled for commit e84d38f. Watch https://buildkite.com/apache-arrow and https://conbench.arrow-dev.org for updates. A comment will be posted here when the runs are complete.

[AntoinePrv]

The regression for mac-arm seems to be quite significant.

It appears similar regression occurs occasionally. I'll restart the benchmark.

Yes, MacOS has no reason to be affected by this (it cannot even run the code we removed), so this one is definitely spurious.

[conbench-apache-arrow]

Thanks for your patience. Conbench analyzed the 4 benchmarking runs that have been run so far on PR commit e84d38f.

There was 1 benchmark result indicating a performance regression:

• Pull Request Run on arm64-t4g-2xlarge-linux at 2026-07-24 19:58:18Z
  • TouchArea (C++) with params=size:65536/real_time/threads:2, source=cpp-micro, suite=arrow-memory-pool-benchmark

The full Conbench report has more details.

[rok]

No more macOS regressions, I think it's just noisy and TouchArea similarly so.