<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi James,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 27, 2015, at 10:04 AM, James Molloy <<a href="mailto:james@jamesmolloy.co.uk" class="">james@jamesmolloy.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi all,<div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div><br class=""></div><div>I totally agree that things are very much lacking in this area.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">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()!)</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I've uploaded my current prototype to Phab here: <a href="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=" class="">http://reviews.llvm.org/D11530</a></div><div class=""><br class=""></div><div class="">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:</div><div class=""> * Is this a useful abstraction? Is it something the community would like to see in-tree (eventually)?</div></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>Thanks for pushing things in this area!</div><div><br class=""></div><div>Adam</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> * Does the API design make sense? Are there obvious things I've missed that people need?</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Any feedback would be gratefully appreciated!</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">James</div></div>
_______________________________________________<br class="">llvm-commits mailing list<br class=""><a href="mailto:llvm-commits@cs.uiuc.edu" class="">llvm-commits@cs.uiuc.edu</a><br class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits<br class=""></div></blockquote></div><br class=""></div></body></html>