Re: [RFC/RFA] [PATCH 02/12] Add built-ins and tests for bit-forward and bit-reversed CRCs

[Jeff Law <jeffreyalaw@gmail.com>]

On 5/27/24 12:38 AM, Richard Biener wrote:
> On Fri, May 24, 2024 at 10:44 AM Mariam Arutunian
> <mariamarutunian@gmail.com> wrote:
>>
>> This patch introduces new built-in functions to GCC for computing bit-forward and bit-reversed CRCs.
>> These builtins aim to provide efficient CRC calculation capabilities.
>> When the target architecture supports CRC operations (as indicated by the presence of a CRC optab),
>> the builtins will utilize the expander to generate CRC code.
>> In the absence of hardware support, the builtins default to generating code for a table-based CRC calculation.
> 
> I wonder whether for embedded target use we should arrange for the 
> table-based CRC calculation to be out-of-line and implemented in a
> way so uses across TUs can be merged?  I guess a generic
> implementation inside libgcc is difficult?
I think the difficulty is the table is dependent upon the polynomial. 
So we'd have to arrange to generate, then pass in the table.

In theory we could have the linker fold away duplicate tables as those 
should be in read only sections without relocations to internal members. 
  So much like we do for constant pool entries.  Though this hasn't been 
tested.

The CRC implementation itself could be subject to ICF if it's off in its 
own function.  If it's inlined (and that's a real possibility), then 
there's little hope of ICF helping on the codesize.

Or we could just not do any of this for -Os/-Oz if the target doesn't 
have a carryless multiply or crc with the appropriate polynomial.  Given 
the CRC table is probably larger than all the code in a bitwise 
impementation, disabling for -Os/-Oz seems like a very reasonable choice.


jeff