zlib-ng / zlib-ng / 29326612570
93%

DEFAULT BRANCH: develop
Ran
Jobs 0
Files 0
Run time –
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
29326612570

push

github

Dead2 
Force post-indexed loads in NEON compare256

When compare256_neon inlines into longest_match, neither clang nor gcc
keeps the two-stream compare loop post-indexed: both emit a base+offset
address plus a separate add per 16-byte step. On clang this is because
loop strength reduction cannot generate post-increment addressing at
all; its isLegalAddressingMode hook has no way to express it, a
long-standing "TODO: handle pre/postinc" [1][2]. Post-indexed loads are
left to the AArch64 load/store optimizer, a post-isel peephole that only
fires for simple loop shapes [3].

The short-match peel restructured the surrounding code enough to move the
loop out of the shape that peephole recognizes, turning a previously
post-indexed clang loop into the extra-add form and regressing the
striped_rgb benchmark. gcc never post-indexed this loop to begin with,
so it carried the extra add on both develop and the PR.

No source-level spelling avoids it; every C formulation funnels through
the same lowering. Pin the post-indexed form with inline asm: one
self-incrementing pointer reaches the other stream at a constant offset,
folding the +16 advance back into the load. The result is byte-identical
and speeds up striped_rgb on both compilers (M5: clang flips it from a
regression to a win, gcc -3% to -6%).

MSVC ARM64 has no inline asm and keeps the plain intrinsic loop.

[1] https://groups.google.com/g/llvm-dev/c/tmC5Elmi_54
[2] https://tcloud.sjtu.edu.cn/pdf/CGO_2025_Postiz.pdf
[3] https://llvm.org/doxygen/AArch64LoadStoreOptimizer_8cpp_source.html
Source Files on build 29326612570
Detailed source file information is not available for this build.