On 15/03/2022, Richard Biener <richard.guent...@gmail.com> wrote: > 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?
Thinking about this a bit more, I suppose I could change the match.pd framework to allow to set a bit or add a list element for a basic block where an expression match is found. That wouldn't make it any simpler - on the contrary, much more complicated, since there need to be another check for the same expression that makes sure all the inputs and outputs line up with the other basic blocks constituting the loop - but it could avoid scanning functions that don't have anything that looks like a match in a separate pass. The proper check and actual transformation would still have to be in its own pass, but that could return immediately if no expression match for a starting block was found. It'd have to be early enough, though, to happen before all inlining and unrolling, since both operations would hinder recognition, and we also want them applied to outer loops / inlining functions after the transformation of the crc computing loop into a built-in function. I suppose if no gimple pass is early enough, we could resort to use a generic match.
