This has possibly been asked before, but I have some understanding of how the rewriting rules in isle work for optimisation, but not how other optimisations (specifically LICM, and other code movement opts such as hoisting and sinking) work. Believe that DCE is done inherently with the representation.
My talk at EGRAPHS 2023 covers this a bit (slides, video). The gist of it is that we're forced to recompute code location anyway during elaboration from egraph back to CFG; so we add a notion of "loop level" and place operators higher if every operand is available higher, and LICM falls out of that.
Thanks, so these are all a function of elaborating the aegraph representation back - guess other loop transforms (unroll / vectorise) would happen there too?
In theory could happen there, yep, though both of those in particular are a little tricky as they require both code-placement / code-duplication logic as well as expression-rewrite logic. I suspect both would be easier once we work out how to have rewrite rules that apply to control flow as well (which is a wide-open problem)
Last updated: Nov 22 2024 at 17:03 UTC