
<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>Hi Richard,</div><div><br></div><div>Thanks for the detailed review!</div><div><br></div><div><div>I went with the last syntax you suggested. Seems simple to me and easily extendable: #pragma clang loop vectorize_width(2) interleave_count(4).</div><div><br></div><div>Also it helped clean up a lot of the ambiguity you talked about in the LoopHintAttr. A single integer Value has replaced the Kind (Enable/Disable/Value) and a integer value there previously. Hopefully it won’t be too difficult to support constant expressions, and non-type template parameters. I’ll work on those patches next.</div><div><br></div><div>I also improved the incompatibility testing as well. I realized there were several cases my previous test wasn’t identifying.</div><div><br></div><div><br></div></div><div><blockquote type="cite"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Objective C is a proper superset of C, so yes. I don't know Objective C very well either, and it might be the case that it would never be possible to vectorize its for loop, because it's too dynamic.</div></div></div></div></div></blockquote><div><br></div><div>Ok, its on my list.</div><div><br></div><div><br></div><blockquote type="cite"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I think you want (and what the approach I described above permits) is to callParseConstantExpression.</div></div></div></div></div></blockquote><div><br></div><div>I think I understand now what you are suggesting. Your thinking that the expression may include more than one token. I gave it a try, but I wasn’t able to get it to work. The expression returned by ParseConstantExpression was always invalid. Perhaps I didn’t implement it correctly. I’m capturing all of the tokens between the brackets and then when handling the annotated token I reinserted them into the stream and called ParseConstantExpression. I tried it with and without the brackets and with and without a trailing eof token. The LHS and Res expressions parsed in ParseConstantExpression were also always invalid <<NULL>>. Lets leave this and other constant expression work for a later patch.</div><div><br></div><div><br></div></div><div>Here is the updated patch.</div><div><br></div><div>Tyler</div><div><br></div><div></div></body></html>