On Mon, May 27, 2024 at 5:16 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > > 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.
I was wondering of doing some "standard" mangling in the implementation namespace and using comdat groups for both code and data? > 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. I was mainly thinking about the case where the user uses the new builtins, but yes, when optimizing for size we can disable the recognition of open-coded variants. Richard. > > jeff
