[llvm-dev] Writing loop transformations on the right representation is more productive

[Michael Kruse via llvm-dev]

Am Mo., 10. Feb. 2020 um 14:52 Uhr schrieb Nicolai Hähnle <nhaehnle at gmail.com>:
> On Sat, Feb 8, 2020 at 7:11 AM Michael Kruse via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > I am not sure that a pass manager is that necessary. It adds flexibility to the optimization process, but as long we don't support dynamically adding transformations, I think organizing the transformations in code is sufficient at the beginning. Since transformations apply on subtrees, are prioritized, and can add candidates to be selected by a cost function, a pass manager has to be structured differently.
>
> It can be convenient to be able to just plug different pass orders
> together in a tool like opt, to explore what happens with different
> pass structures.

Such a tool would need to know to which subtree apply to, or define a
traversal order (such as innermost-to-outer, revisit modified subtrees
and apply each transformation at most once). I currently don't know
what makes most sense.

For regression test, I'd prefer to use unittests: A test has a
reference to node, applies the transformation, and validates the
result by introspection/visitor/matcher pattern.


> I've actually seen a bunch of code with loops that would traditionally
> be considered quite weird, where loop unrolling unlocks a huge number
> of InstCombine and even SimplifyCFG opportunities to the point where
> after loop unrolling, the code is barely larger than the original
> code. So being able to speculatively combine not just loop passes but
> also generic IR passes is definitely interesting.

Really interesting scenario, it might be worth it implementing a
subset of InstCombine on the tree representation. In contrast, I'd
have no clue how to make the current LoopUnroll heuristic consider
this.

Michael

-- 

> --
> Lerne, wie die Welt wirklich ist,
> aber vergiss niemals, wie sie sein sollte.

Wenn wir uns nur darauf einigen könnten, wie sie sein solle ;-)