<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>I don’t think we should separate the option interleave from the pragma vectorize. I mean, we should use the syntax #pragma vectorize {interleave(_value_), width(_value_), enable, disable}, because interleave and vectorization are related, enable/disable don’t add anything that isn’t already part of pragma vectorize enable/disable, and specifying `#pragma vectorize disable’ would disable interleaving.</div><div><br></div><div>As for safety, how about #pragma vectorize aggressive?</div><div><br></div><div>Tyler</div><div><br></div><div>On Apr 22, 2014, at 12:56 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 22, 2014 at 12:47 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> I very much dislike the term 'interleave'. We had a great deal of<br>
> trouble with this term in the C++ committee. There are execution<br>
> models which want this information but do not guarantee<br>
> "interleaved" execution, and this is observable.<br>
<br>
</div>In this particular case, I think this objection is misplaced. The particular transformation that we're discussing is, literally, one that provides interleaving of loop iterations. We could also call it unsequenced (as I mentioned in some earlier e-mail), but in some sense, this transformation is more specific than that.<br>
</blockquote><div><br></div><div>I understand that. But I'm somewhat concerned *promising* it in the pragma. It seems better to use a more generic term if there is a good one that applies, and widen seems to.</div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> If this is just a cost model hint, I like "widen" quite a bit better,<br>
> and maybe there is a way to work "hint" or "cost" into the name?<br>
<br>
</div>In some sense it is a cost model hint, but I'm not sure a user would see it as such.<br></blockquote><div><br></div><div>Yea, I see that too.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Using hint for the non-safety-asserting variants seems like a good idea. We should be clear with the users whether they are providing only a hint, or asserting something more.</blockquote><div><br></div><div>Indeed. This is the key part. </div>
</div></div></div>
_______________________________________________<br>cfe-commits mailing list<br><a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits<br></blockquote></div><br></body></html>