On 11/28/25 12:16 PM, Andrew Pinski wrote:
On Fri, Nov 28, 2025 at 2:00 AM Kito Cheng <[email protected]> wrote:
I know we're already in stage 3, so I'm basically asking for a review and am
fine with deferring this to GCC 17. But if it's acceptable for GCC 16, that
would be great too. :P
---
The previous reversed CRC implementation used explicit bit reflection
before and after the CRC computation:
reflect(crc_init);
reflect(data);
for (int i = 0; i < data_bit_size / 8; i++)
crc = (crc << 8) ^ table[(crc >> (crc_bit_size - 8))
^ (data >> (data_bit_size - (i+1) * 8) & 0xFF)];
reflect(crc);
This patch generates a reversed polynomial lookup table directly,
eliminating the need for bit reflection operations. The new algorithm:
for (int i = 0; i < data_bit_size / 8; i++)
crc = (crc >> 8) ^ table[(crc ^ (data >> (i * 8))) & 0xFF];
This improves code generation for all targets using table-based reversed
CRC, as it removes the overhead of reflecting input data and CRC values.
The one question I have is this local decision or done globally? For
-Os (maybe it is already done I didn't check), if the program does
both the reversed and non-reversed poly in the same program, won't it
be smaller to always do the non-reversed poly as the table to share
the table between the 2?
Mariam and I went through about 10k Fedora packages to identify
implementations in the wild, I don't think we encountered any cases
where there was a reversed and a normal CRC in the same package. So it
may not be worth the headache.
Jeff
