RFC: LoopEditor, a high-level loop transform toolkit

[Adam Nemet]

Hi  James,

> On Jul 27, 2015, at 10:04 AM, James Molloy <james at jamesmolloy.co.uk> wrote:
> 
> Hi all,
> 
> LLVM currently lacks a single coherent way to edit, modify and transform loops. We have the Loop abstraction that provides some functionality, and we have a cluster of functions and abstractions in LoopUtils, but each is fairly cumbersome to use. There's also VersionedLoop, but that's quite specific and not really extendable/composable.

I totally agree that things are very much lacking in this area.

> 
> I've recently been trying to do some prototyping of a high level loop optimization (unroll-and-jam) and ended up with quite a bit of spaghetti code doing what should be simple transforms (as another example, look at LoopVectorize::createEmptyBlock()!)
> 
> So I decided to prototype an API for performing more high level operations on LLVM Loops - cloning, widening, interleaving, stitching the output of one loop into another loop, setting loop trip counts, peeling... and all while keeping loopinfo, domtree and SCEV updated.
> 
> I've uploaded my current prototype to Phab here: http://reviews.llvm.org/D11530 <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11530&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=3t7gCOgkqnA-65i6cez_eslTon3hxx5XJKhMBw98kv0&s=yCaxJfCogeqwUH-wlsdHFPHktniLwG3-cZnq1yciR04&e=>
> 
> It's still at the prototype stage so there are lots of things that need fixing - sorting out the testing story being top of my list. But I'm looking for feedback on:
>   * Is this a useful abstraction? Is it something the community would like to see in-tree (eventually)?

I probably won’t have time to read the patch in detail for the next couple of days but I did peek a little bit in the patch.  My impression is that you’re trying to generalize some of the vectorizer functionality so that it could be used by other passes.  I do see a parallel here to what I did with LAA so my comments are heavily influenced by that.

I would prefer abstracting out the functionality one by one with NFC patches.  This is probably more work than the whole-sale transition but it’s probably the only reasonable way to get meaningful reviews.  This also gives everybody the warm fuzzy feeling that we’re not losing functionality.  My approach was to get buy-ins at the big decisions points like the proper abstraction, new APIs and then have post-commit review with simple refactoring patch that prepare the code for building up the new abstraction.

I also have some doubts about a big all-encompassing LoopEditor class.  There are many passes that are only interested in certain aspect of the loop, e.g. LoopDistribution does not care about reductions for example and some other transformation may not care about LAA unless they want to reason about mem dependences/insert memchecks.

So a design that is pretty decomposed even at the class level may be better.  We could also push the functionality into analysis passes if the analysis turns out to be somewhat expensive/cachable.

Again, this are only first impressions at this point without looking too much into the code but I thought I threw them out to get the conversation going.

Thanks for pushing things in this area!

Adam


>   * Does the API design make sense? Are there obvious things I've missed that people need?
> 
> I've thought about the use cases of the loop vectorizer, loop distribution, loop unrolling, loop versioning, and I think the current design can solve their use cases fairly elegantly. I've used this API to write a fairly sophisticated unroll-and-jam transform in very few lines too.
> 
> Any feedback would be gratefully appreciated!
> 
> Cheers,
> 
> James
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150729/9394a12b/attachment.html>