Re: [PATCH] lib/xz: Decode LZMA with local range decoder and dictionary state

[Lasse Collin <lasse.collin@tukaani.org>]

On 2026-11-13 Paul Menzel wrote:
> lzma_main() and the functions it calls access the range decoder and
> the dictionary through s->rc and s->dict. Every decoded bit stores to
> a uint16_t probability, and every decoded byte stores to dict.buf, and
> the kernel builds with -fno-strict-aliasing. So the compiler has to
> assume that these stores modify *s, and reloads and stores rc.range,
> rc.code, rc.in_pos, dict.pos, dict.full, … around each of them.
> 
> Copy both structures to local variables at the start of lzma_main()
> and write them back at the end, and force inlining of the helpers that
> take their address, so that the compiler can keep them in registers.

I tested quickly, but I cannot comment properly yet, sorry. I hope I can
some day next week.

> liblzma’s LZMA decoder does the same [1]: lzma_decode() works on a
> local copy of the dictionary, and rc_to_local() makes a local copy of
> the range decoder.

It was done when GCC 3.3 and 3.4 were still in common use. Maybe
aliasing is one reason why it helped. Maybe it was that variables on
stack can be accessed directly via the stack pointer, which could have
mattered on register-starved 32-bit x86. I haven't checked how big
difference it makes in liblzma nowadays.

> liblzma has copied the range decoder since the first commit of the xz
> repository in 2007 [2], and the dictionary since a restructuring in
> 2008 [3], first released in xz 4.999.5alpha.

History about non-kernel code isn't needed in the commit message.

In late 2023 or very early 2024, I wrote some compact x86-64 inline
assembly for XZ Embedded, but I never polished and released it. I try to
finish it.

Thanks!

-- 
Lasse Collin