On 5/27/24 12:38 AM, Richard Biener wrote:
On Fri, May 24, 2024 at 10:44 AM Mariam Arutunian
<mariamarutun...@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
