[cfe-dev] Adding a new pragma to Clang

[Arnold Schwaighofer]

On Jan 6, 2014, at 8:02 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
>> From: "Alp Toker" <alp at nuanti.com>
>> To: "Renato Golin" <renato.golin at linaro.org>, "Hal Finkel" <hfinkel at anl.gov>
>> Cc: "Richard Smith" <richard at metafoo.co.uk>, "Clang Dev" <cfe-dev at cs.uiuc.edu>
>> Sent: Monday, January 6, 2014 9:42:01 AM
>> Subject: Re: [cfe-dev] Adding a new pragma to Clang
>> 
>> 
>> On 06/01/2014 15:32, Renato Golin wrote:
>>> On 6 January 2014 15:20, Hal Finkel <hfinkel at anl.gov
>>> <mailto:hfinkel at anl.gov>> wrote:
>>> 
>>>    I think he'll need something very close to the OpenMP syntax.
>>> 
>>> 
>>> Or that.
>>> 
>>> I don't really mind *how* it's represented in C code, as long as it
>>> does what we need in IR in the long run: lexical block level
>>> metadata.
>> 
>> The C frontend syntax is the one that's going to ship and get used in
>> tens of thousands of software projects, and which we might still be
>> having to support 15 years later when the CPU architectures have all
>> changed. It's quite likely in that lifetime that other vendors will
>> try
>> to do a compatible implementation too if it sees adoption.
> 
> I recommend that, where practical, we use a syntax compatible with other implementations. For example, Intel's compiler implements some of these which I believe we'd like to have:
> 
>  ivdep
>  loop_count
>  vector/novector
>  unroll/nounroll
> 
> http://software.intel.com/sites/products/documentation/doclib/iss/2013/compiler/cpp-lin/GUID-346BAAA5-CF2D-4A26-9194-CA840BFB34E5.htm
> 
> IBM's compiler also has a few of these (unroll, novector, etc.):
> 
> http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Fcompiler%2Fref%2Frupragen.htm


I think it is okay for clang to develop its own coherent syntax. If we take syntax from different compilers we get non-coherent syntax and users will probably still have to use macros because different compilers and compiler versions will support a different set of those directives (ivdep, simd, openmp, etc) with possibly a slightly different semantics, or requirements (for examples, Intel’s simd pragma requires the loop induction variable to be signed).

Renato is trying to add pragmas that control the vectorizer. For this, I think an intuitive syntax interface would be a "#pragma subject attribute(value), attribute(value), ..." structure.

#pragma vectorize enable/disable
for () {
  a[i] = ...
}

#pragma vectorize unroll(4)
for () {
  a[i] = ...
}

#pragma vectorize width(4)
for () {
  a[i] = …
}

#pragma vectorize safe(...)
for () {
  a[i] = …
}

http://llvm.org/bugs/show_bug.cgi?id=18086#c0 has some comments about what those attributes do.

> 
>> 
>> So from my point of view the backend implementation, and even the AST
>> representation if there is any, is a secondary almost trivial issue
>> compared to specifying a new extension to the language. But that's my
>> take as a parser maintainer  :-)
>> 
>> Incidentally I don't think there needs to be an AST representation as
>> such. This looks like it can be supported with a lookup map for
>> statements / expressions, and synthesized attributes for functions.
>> 
>> The list of commands you posted in the previous email is a good
>> starting
>> point, but I'd like to see real code samples of what you want to
>> work.
>> 
>> Can it annotate statements, declarations or both? Is it expected to
>> survive through template instantiations?
> 
> Yes.
> 
>> Do the directives require
>> semantic analysis?
> 
> This is an interesting point; some of them might.
> 
>> Those are the questions that'll determine how this
>> is
>> implemented.
>> 
>> Hal's suggestion to plug into the OpenMP directives is also very
>> interesting.
> 
> Just trying to figure out how to not reinvent the wheel yet again ;)

I think openmp is a separate language extension that can reuse common infrastructure. I think it is beneficial for clang to have its own syntax tailored to the functionality of clang (for example: clang recognizes reductions and inductions; in opemmp you seem to have to annotate them as reduction and linear).

In my opinion, clang vector pragmas should be easy to understand and use and be tailored to the functionality that the clang/llvm infrastructure provides.


Thanks,
Arnold