RFC: LoopEditor, a high-level loop transform toolkit

James Molloy james at jamesmolloy.co.uk
Mon Jul 27 10:04:25 PDT 2015


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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150727/aa449f7d/attachment.html>


More information about the llvm-commits mailing list