Hi Richard, Thanks for the detailed review! I went with the last syntax you suggested. Seems simple to me and easily extendable: #pragma clang loop vectorize_width(2) interleave_count(4). 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. I also improved the incompatibility testing as well. I realized there were several cases my previous test wasn’t identifying.
Ok, its on my list.
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. Here is the updated patch. Tyler |
pragma_loop-svn.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
