On Mon, Jun 30, 2014 at 9:52 AM, Chandler Carruth <[email protected]>
wrote:

>
> On Thu, Jun 26, 2014 at 9:49 AM, Mark Heffernan <[email protected]> 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.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to