RFC: LoopEditor, a high-level loop transform toolkit

[James Molloy]

Hi Adam,

> Do you mean LoopVersioning or is this something different?

Yes, sorry, I do mean LoopVersioning. It's a good start, but the API isn't
flexible enough at the moment to build on. My proposed LoopEditor API would
provide some of the features of LoopVersioning but not all - for example it
wouldn't know about LoopAccessAnalysis and runtime pointer checks. So
LoopVersioning could be trivially bolted on to this API.

James

On Mon, 27 Jul 2015 at 18:27 Adam Nemet <anemet at apple.com> wrote:

> 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/f24226ae/attachment.html>