On Fri, Nov 28, 2025 at 11:30 AM Jeff Law <[email protected]> wrote: > > > > 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.
That makes sense so my question about -Os is withdrawn. Though it would be a good idea to put this in the commit message for quick access for the future. Thanks, Andrew > > Jeff
