[cfe-dev] Adding a new pragma to Clang

[Renato Golin]

On 6 January 2014 15:42, Alp Toker <alp at nuanti.com> wrote:

> So from my point of view the backend implementation, and even the AST
> representation if there is any, is a secondary almost trivial issue
> compared to specifying a new extension to the language. But that's my take
> as a parser maintainer  :-)
>

Right... "I don't care" == "I'm not qualified to choose the best
representation, whatever front-end folks think it's best, I'm fine with
it". :D

I agree with your rationale to the letter and whatever you guys think it's
the most future proof, we'll go with it.


Can it annotate statements, declarations or both? Is it expected to survive
> through template instantiations? Do the directives require semantic
> analysis? Those are the questions that'll determine how this is implemented.
>

Adding Arnold, as he was the one planning all this...

AFAIK, it's supposed to annotate statements only, not declarations. It
should survive anything the pre-processor can throw, but templates will be
a big problem if the types change between instantiations for enable, unroll
and width. If I got it right, safety pragmas should be on. A
safe-with-dist(N) will only apply if the type * lanes can fit into the
vector registers, so it should be safe to annotate a templated loop and let
the vectorizer decide if it's still safe or not.

The idea is to proceed in these steps:

1. Add enable/width/unroll to loops only. So far, only the loop vectorizer
will be looking at these. No nesting, since the loop-vectorizer can only
work on inner-most loops. Metadata added to outer loops will be ignored and
a warning should be printed to the user, I don't expect the front-end to
know all use cases and descend the loop tree automatically.

2. Add enable/width/unroll to lexical blocks (functions, ifs, blocks) but
not namespaces, structures, classes, declarations, definitions, etc. This
way, the SLP-vectorizer can also be controlled via these flags. Similar
metadata semantics as above.
 2.a Work out if we want to nest pragmas. If so, an *if* inside a
*function* (both with pragmas) should have their metadata:
  * plain, and it'll be the job of the vectorizer to walk down the lexical
blocks to find additional parameters, or
  * merged, and the front-end should annotate in an local-override-global
manner and the vectorizer only reads the local metadata.
  * This will depend on how inlining will change the semantics of the code.
It's too early to think about this, I think.

3. Add safe pragmas with the same constraints as the ones above. This
should be done only *after* safety analysis is implemented in the
vectorizer, and should be the simplest part of the front-end change, since
all the work should've been done already by 1 and 2.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140106/47658dfe/attachment.html>