On Tue, Mar 15, 2022 at 1:32 AM Joern Rennecke <joern.renne...@embecosm.com> wrote: > > Most microprocessors have efficient ways to perform CRC operations, be > that with lookup tables, rotates, or even special instructions. > However, because we lack a representation for CRC in the compiler, we > can't do proper instruction selection. With this patch I seek out to > rectify this, > I've avoided using a mode name for the built-in functions because that > would tie the semantics to the size of the addressable unit. We > generally use abbreviations like s/l/ll for type names, which is all > right when the type can be widened without changing semantics. For > the data input, however, we also have to consider the shift count that > is tied to it. That is why I used a number to designate the width of > the data input and shift. > > For machine support, I made a start with 8 and 16 bit little-endian > CRC for RISCV using a > lookup table. I am sure once we have the basic infrastructure in the > tree, we'll get more > contributions of suitable named patterns for various ports.
Why's this a new pass? Every walk over all insns costs time. The pass lacks any comments as to what CFG / stmt structure is matched. From a quick look it seems like it first(?) statically matches a stmt sequence without considering intermediate stmts, so matching should be quite fragile. Why not match (sub-)expressions with the help of match.pd? Any reason why you match CRC before early inlinig and thus even when not optimizing? Matching at least after early FRE/DCE/DSE would help to get rid of abstraction and/or memory temporary uses. > bootstrapped on x86_64-pc-linux-gnu .
