[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

>  * 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?


More information about the cfe-dev mailing list