I'm happy with the slice-by-8 code I have < https://github.com/samrussell/gnulib/blob/slice_by_8/lib/crc.c> but the cksum_pclmul implementation is quite detailed so it would be useful if we could relicense that for gnulib.
There's a minor optimisation around dealing with a non-round number of bytes, the slice-by-n algorithm generalises to something like this: CRC(plaintext ^ (n bytes of crc' << n - 32)) ^ crc' >> n*8 the special case of slice-by-4 gives us: CRC(plaintext ^ crc') and slice-by-8 gives us CRC_HIDWORD(HIDWORD(plaintext) ^ crc') ^ CRC_LODWORD(LODWORD(plaintext)) which is also CRC((crc' << 32) ^ plaintext) it's probably not worth overoptimising for the final n<8 bytes but i also do like having an elegant solution, especially if we pair this with a basic description of the theory in the comments. adding a slice-by-n lets us do multiple slices of 8 and then the final 1-8 in a single memory access if that's important On Tue, 15 Oct 2024 at 13:05, Pádraig Brady <p...@draigbrady.com> wrote: > On 15/10/2024 08:07, Simon Josefsson wrote: > > The coreutils code is GPL and the crc module in gnulib is LGPL. I'm > > using the gnulib crc module in some LGPL projects. Is it wortwhile to > > keep the optimization GPL? I would prefer a LGPL crc module that is > > performant, with #ifdef-varianted support for 1) no tables at all, 2) > > small table like today, and 3) your bigger tables, together with support > > for the SSE instruction. If that makes sense and would work. Thoughts? > > Otherwise another approach is to keep a simple LGPL crc module and > > performant crc-gpl module that uses the coreutils code. > > We occasionally relicense code from GPL to LGPL where appropriate. > Kristoffer would you be OK with doing this to facilitate > the code being more widely used? > > In any case, coreutils will adjust to the single implementation > in gnulib when available. > > thanks! > Pádraig >
