<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 23, 2013 at 10:37 AM, Arnold Schwaighofer <span dir="ltr"><<a href="mailto:aschwaighofer@apple.com" target="_blank">aschwaighofer@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
On May 23, 2013, at 9:15 AM, Renato Golin <<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>> wrote:<br>
<br>
> On 23 May 2013 14:52, Arnold Schwaighofer <<a href="mailto:aschwaighofer@apple.com">aschwaighofer@apple.com</a>> wrote:<br>
> I would like us to grow a few annotations, among others, one to force vectorization irrespective whether the loop vectorizer thinks it is beneficial or not - however, this is future music.<br>
><br>
> Isn't that part of the ivdep implementation? I thought there was support for that already...<br>
<br>
</div></div>No, llvm.loop.parallel only communicates information about memory dependencies (or there absence of) and the loop vectorizer only uses it for this. I don’t think we should give it additional semantics of forcing vectorization.<br>

<br>
Of course, you could locally patch llvm to abuse it for other purposes...<br>
<br>
<br>
(Note, I have not formed a strong opinion on this yet, these are just some initial thoughts, I am not convinced yet that the attributes below are the right set of attributes, or that the syntax is right ;)<br>
<br>
I am thinking of something like:<br>
<br>
llvm.vectorization.<param><value><br>
<br>
<br>
where which would allow us to safety and optimization parameters from the front end:<br>
<br>
<br>
- Safety:<br>
 #pragma vectorize [max_iterations <NUM>]<br>
<br>
 For vectorization we might want to have an optional parameters at which distance vectorization is safe:<br>
 #pragma vectorize max_iterations 8<br>
 would indicate that vectorization up to a distance 8 is safe. This would restrict the combinations of VF and unroll factor the vectorizer is allowed to choose.<br>
<br>
- Parameters controlling the vectorizer optimization choices:<br>
 width, unroll factor, force vectorization at Os, don’t vectorize<br>
<br>
#pragma vectorize width 4 unroll 2<br>
Forces VF=4 and unroll=2<br>
<br>
#pragma vectorize max_iterations 8<br>
Allows the vectorizer to choose.<br>
<br>
#pragma vectorize off<br>
Disable vectorization.<br>
<br>
#pragma vectorize force<br>
<br>
<br>
If we decide, that<br>
<br>
#pragma ivdep<br>
<br>
should imply forced vectorization (which I am not sure it should), the front-end can than in addition to the llvm.loop.parallel metadata, emit meta data to force vectorization. But, I don’t think we should overload the semantics of llvm.loop.parallel.</blockquote>
<div><br></div><div>I'm not sure that ivdep should "force vectorization" either. My interpretation of this pragma is that it tells the compiler not to consider "assumed" dependencies. "Proven" dependencies are still valid, which can prevent vectorization. </div>
<div><br></div><div style>I apologize in advance if this seems nit-picky.</div><div style><br></div><div style>-Cameron</div></div></div></div>