Support non-type template parameters in #pragma loop

[Tyler Nowicki]

Hi Richard,

Thanks for the review.

You’ve suggested copying HandlePragmaMSPragma, however, the behavior is already nearly identical. My own pragma parsing does some up-front error checking and then puts the relevant tokens into a structure that is attached to an annotated token. MSPragma does no up-front error checking and puts all tokens into a list that is attached to an annotated token. During parsing of the loop hint annotated token sema (ActOnLoopHintValue) handles all cases for the loop hint argument. During parsing of the MSPragma annotated token some delegates handle each flavor of mspragma and make calls to sema. If there is something I’ve missed here please let me know what that is.

We’ve invented this pragma. We have also already had a long discussion on its syntax in the `#pragma vectorize’ thread. The consensus was for the pragma to take ‘enable’, ‘disable’, and a non-type template argument. I don’t see why adding constant expressions should be a problem. I will do this in a follow-up commit.

If you have any suggestions for an alternate syntax please let us know. We would be very interested in hearing your suggestions.

Also, would you please review the patch in the `#pragma vectorize’ thread. This is my third ping.

Thanks,

Tyler

On May 26, 2014, at 9:55 AM, Richard Smith <richard at metafoo.co.uk> wrote:

> On Fri, May 23, 2014 at 2:41 PM, Tyler Nowicki <tnowicki at apple.com> wrote:
> Hi,
> 
> As requested here is the patch to support non-type template parameters in #pragma loop. The patch uses LookupName to build a DeclRefExpr to the template parameter and overloads TransformAttr in the template instantiator to transform the value expression and replace the LoopHintAttr. It is built on the PragmaAttr and Pragma Spelling patch listed in the 'Add PragmaAttr and Pragma Spelling to Tablegen’ thread. Since it is a git patch please use ‘patch -p1’ to apply it.
> 
> This seems like fundamentally the wrong approach to me. It doesn't make much sense to me to accept only an identifier here; at a minimum you should accept an id-expression, and ideally you should accept any constant-expression. And that in turn means your approach of parsing the pragma from the lexer is unworkable -- you need to move the parsing logic to the parser in order to be able to actually parse an id-expression / constant-expression. See HandlePragmaMSPragma for an example of an existing pragma that does this.
> 
> Is there some pre-existing standard / specification we're implementing here, or is this a pragma of our own invention?
> 
> Also:
> 
> +  if (ValueName == "enable" || ValueName == "disable")
> +    return ExprEmpty();
> 
> If this is a pragma we invented, can we design it such that we don't have an ambiguity between its pseudo-keywords and its identifier lookup?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140527/acd239f6/attachment.html>