[PATCH] Add support for CUDA unroll pragma

[Richard Smith]

On Mon, Jun 30, 2014 at 9:52 AM, Chandler Carruth <chandlerc at google.com>
wrote:

>
> On Thu, Jun 26, 2014 at 9:49 AM, Mark Heffernan <meheff at google.com> wrote:
>
>> From a previous review Richard Smith (cc'd) had a strong opinion about
>> placing the loop pragmas inside of the clang namespace ("#pragma clang
>> loop...").  Clearly this is incompatible with "#pragma unroll ...".
>>  Richard, any thoughts on this?
>
>
> I can't speak for Richard, but my take on it would be this:
>
> For an invented syntax, it should go under the clang namespace.
>
> For a syntax designed to be compatible with some other system (Intel, IBM,
> or CUDA) we should match their syntax exactly, as otherwise there is no
> point in "compatibility".
>
> I'm personally very comfortable with Clang supporting a relatively diverse
> set of syntaxes for specifying this behavior in order to increase
> compatibility with other compilers that we would otherwise already be
> compatible with (IBM and Intel seem likely) or which there are specs that
> we should follow (CUDA). I would probably allow the CUDA-compatible syntax
> only in CUDA mode (and similarly other compatible syntaxes if there is a
> comparable narrow area where the compatibility matters), but it doesn't
> seem to be a deal breaker either way.
>

I basically agree with all of this. In CUDA mode we should obviously
support the CUDA syntax. For compatibility with icc and xlc we should
support the form with parens. I don't see any particularly good reason to
prohibit the CUDA form outside of CUDA mode.

One question: you list the unroll count as 'n'. Must that be a constant
integer? The clang pragma intends to allow an arbitrary integer constant
expression there. That might be a good reason for us to introduce our own
syntax for it, if we're providing a slightly more general form.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140701/64768737/attachment.html>