[cfe-dev] RFC: User-directed code transformations with #pragma clang transform
David Greene via cfe-dev
cfe-dev at lists.llvm.org
Wed Dec 18 07:37:32 PST 2019
Hi Michael, thanks for this RFC! I just have a few questions and
comments to start off.
Are these pragmas meant to be advisory or prescriptive (when legal)?
>From your description and motivation I assume the latter but I wanted to
double-check.
> * Hints are emitted in form of metadata (MDNode) that can be dropped
> by mid-end optimizers
Below you state that metadata will be used to encode the transformations
and order. Doesn't this suffer from the same problem?
> The selection is currently limited to the passes LLVM currently
> supports. I am working on more transformations that currently are only
> picked-up by Polly. The largest difference to loop hints is that it
> allows to specify in which order the transformations are applied,
> which is ignored by clang's current LoopHint attribute. That is, the
> following for reverses the loop, then unrolls it.
>
> #pragma clang transform unroll partial(2)
> #pragma clang transform reverse
> for (int i = 0; i < 128; i+=1)
> body(i);
This seems unintuitive to me. I would expect this to unroll first and
then reverse. I get the "inner-to-outer" ordering you present here, but
I wonder if it will be too easy for users to get something unexpected.
Will it be possible to list multiple transformations with one directive?
#pragma clang transform reverse, unroll partial(2)
If so, then the "inner-to-outer" ordering seems even more problematic:
#pragma clang transform reverse, unroll partial(2)
#pragma clang transform distribute, vectorize
In what order are the transformations applied?
> Furthermore, I intend to implement assigning identifiers to loop to
> reference them in followup transformations (e.g. tile a loop,
> parallelize the generated outer loop and vectorize the inner),
Do you have an example of this idea?
-David
More information about the cfe-dev
mailing list