On Sat, Sep 2, 2017, at 02:42, Hal Finkel wrote:
> Hi everyone,
Hi Hal! Protonu and Mary, good to meet you here! Hi Cy!
> Some of my colleagues and I are interested in understanding how we might
> have fine-grained control over the transformations that Polly performs
> in two contexts:
>
> 1. For tuning by autotuning software (e.g., CHiLL).
>
> 2. For tuning by the programmer (via pragmas, attributes, or similar).
That's a very good idea. We have been thinking in this direction for a
long time, I would certainly like to get involved.
> The best mechanism for both categories might be the same, but I can
> easily imagine it being different. For example, autotuning software
> might simply insert some pragma in the source code in order to name a
> particular loop nest and/or region and then provide a detailed
> transformation recipe via some other input file (something like using
> -polly-import/-polly-export).
You can use -polly-import / -polly-export already today. Each file will
have a unique name per scop, and already provides information which
function it is derived from. We could likely add 'marking metadata' to
identify specific
source code loop nests and add this information into the exported files.
> For programmer-directed tuning, I can imagine extending Clang's existing
> loop pragma
> (
http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations)
> with additional clauses for transformations that Polly supports, plus
> potentially teaching Polly to understand some of the existing clauses
> (e.g., for unrolling/interleaving or vectorization). For
> unrolling/interleaving, Polly might perform the optimization itself, or
> as with vectorization, it might simply prepare for the later
> transformation.
A related project is loopy, which allows for C/C++ pragmas to drive loop
transformations. It is based on Polly, but not available upstream:
https://github.com/nimit-singhania/loopy
> This means that a loop annotated with #pragma clang loop
> vectorize_width(n) would be akin to setting
> -polly-vectorize=stripmine/-polly-prevect-width=n for the relevant loop
> nest.
That's possible.
> To the existing pragma clauses, we'd need to add something that allows
> control over tiling. For example, tile(enable/disable) and tile_size(n).
> We could also add pragmas for interchange, fusion, etc. For fusion, we
> could use a loop-level pragma (and then potentially fuse loops all
> marked for fusion), use some region-marking scheme (such that we might
> fuse all loops within the region), or some naming scheme with a pragma
> taking a list of names (as IBM did in [1]). Finally, we should add some
> clause for enabling/disabling polyhedral transformations in total.
Sounds all very good!
> These would be translated into metadata, similar to the current loop
> hints, and then read by Polly (as an alternative to using settings from
> defaults or command-line parameters).
>
> I'd appreciate any thoughts or pointers to relevant/useful prior art
> (the only thing I know about in this space is [1]).
There is Vikram's autotuning presented at EuroLLVm this year.
There is somewhere a patch in
reviews.llvm.org to build up a search
space tree for optimizations in LLVM (AFAIK it was submitted to do code
size tuning). I was listed as reviewer, but could not find it quickly
As mentioned in the thread on the LLVM mailing list, we have now a
incremental scheduler in isl. This means, it should be possible to add
an interface that allows to tune specific loop scheduling decisions.
Best,
Tobias
> --
> You received this message because you are subscribed to the Google Groups
> "Polly Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
polly-dev+...@googlegroups.com.
> For more options, visit
https://groups.google.com/d/optout.