<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 6 January 2014 15:42, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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  :-)<br>
</blockquote><div><br></div><div>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</div><div>
<br></div><div>I agree with your rationale to the letter and whatever you guys think it's the most future proof, we'll go with it.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote><div></div></div><br></div><div class="gmail_extra">Adding Arnold, as he was the one planning all this...</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">The idea is to proceed in these steps:</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"> 2.a Work out if we want to nest pragmas. If so, an *if* inside a *function* (both with pragmas) should have their metadata:<br></div><div class="gmail_extra">  * plain, and it'll be the job of the vectorizer to walk down the lexical blocks to find additional parameters, or</div>
<div class="gmail_extra">  * merged, and the front-end should annotate in an local-override-global manner and the vectorizer only reads the local metadata.</div><div class="gmail_extra">  * This will depend on how inlining will change the semantics of the code. It's too early to think about this, I think.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">cheers,</div><div class="gmail_extra">--renato</div></div>