On 15/03/2022, Richard Biener <richard.guent...@gmail.com> wrote: > Why's this a new pass? Every walk over all insns costs time.
If should typically scan considerably less than all the insns. > The pass > lacks any comments as to what CFG / stmt structure is matched. I've put a file in: config/riscv/tree-crc-doc.txt would this text be suitabe to put in a comment block in tree-crc.cc ? > From > a quick look it seems like it first(?) statically matches a stmt sequence > without considering intermediate stmts, so matching should be quite > fragile. It might be fragile inasmuch as it won't match when things change, but the matching has remained effective for seven years and across two architecture families with varying word sizes. And with regards to matching only what it's supposed to match, I believe I have checked all the data dependencies and phis so that it's definitely calculating a CRC. > Why not match (sub-)expressions with the help of match.pd? Can you match a loop with 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. I haven't originally placed it there, but I believe benefits include: - Getting rid of loop without having to actively deleting it in the crc pass (this also might be safer as we just have to make sure we're are computing the CRC, and DCE will determine if there is any ancillary result that is left, and only delete the loop if it's really dead. - The optimized function is available for inlining.
