RFC: LoopEditor, a high-level loop transform toolkit

[Adam Nemet]

> 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.

Hi James,

I haven’t read this in detail yet but  but I have a quick question.  What do you mean by VersionedLoop here?  Do you mean LoopVersioning or is this something different?

Adam

> 
> 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)?
>   * 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/20150727/ac6c634e/attachment.html>