[cfe-dev] Adding a new pragma to Clang

[Alp Toker]

On 08/01/2014 14:27, Hal Finkel wrote:
> ----- Original Message -----
>> From: "Aaron Ballman" <aaron at aaronballman.com>
>> To: "Hal Finkel" <hfinkel at anl.gov>
>> Cc: "Arnold Schwaighofer" <aschwaighofer at apple.com>, "Nadav Rotem" <nrotem at apple.com>, "Richard Smith"
>> <richard at metafoo.co.uk>, "Clang Dev" <cfe-dev at cs.uiuc.edu>
>> Sent: Wednesday, January 8, 2014 8:22:18 AM
>> Subject: Re: [cfe-dev] Adding a new pragma to Clang
>>
>> On Wed, Jan 8, 2014 at 9:18 AM, Hal Finkel <hfinkel at anl.gov> wrote:
>>> ----- Original Message -----
>>>> From: "Arnold Schwaighofer" <aschwaighofer at apple.com>
>>>> To: "Hal Finkel" <hfinkel at anl.gov>
>>>> Cc: "Alp Toker" <alp at nuanti.com>, "Richard Smith"
>>>> <richard at metafoo.co.uk>, "Clang Dev" <cfe-dev at cs.uiuc.edu>,
>>>> "Renato
>>>> Golin" <renato.golin at linaro.org>, "Nadav Rotem" <nrotem at apple.com>
>>>> Sent: Tuesday, January 7, 2014 5:19:26 PM
>>>> Subject: Re: [cfe-dev] Adding a new pragma to Clang
>>>>
>>>>
>>>> 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).
>>> And you'll note that I specifically omitted Intel's simd pragma
>>> from the list above ;)
>>>
>>>> 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.
>>> I agree with this, up to a point. We need to be careful about
>>> exposing implementation details at this level, not only because it
>>> is unfriendly, but because those details might change in the
>>> future. The fact that the vectorizer, as a monolithic object,
>>> handles these things now, and is essentially the only user of this
>>> information currently, does not mean it will always be this way.
>>>
>>> For unrolling, I'm specifically against tying the syntax in any way
>>> to the vectorizer. The vectorizer can unroll without vectorizing,
>>> and that's an implementation detail. We also have a generic
>>> (concatenation) unroller, and that should also be controlled by
>>> the same syntax. I propose that, for unrolling we accept something
>>> like this:
>>>
>>> #pragma nounroll[(interleave/concatenate/all)] -- all is the
>>> default
>>> #pragma unroll[(n[, interleave/concatenate/any])] -- any is the
>>> default
>>>
>>> so that the user can, optionally, specify what kind of unrolling to
>>> perform.
>>>
>>> If you really want a 'subject' in the pragma, we could use 'loop'
>>> to give us something like #pragma loop nounroll, etc.
>> Note: I have no skin in this game. But C++11 has sane attributes that
>> you may want to use instead of a pragma. They can be placed on
>> statements as well as declarations (they can be placed on just about
>> anything, actually). This would then give the information an AST
>> representation that might prove useful in other ways that a pragma
>> would not.  Just a random thought.
> I'd like to see both. We do need to support C, C++O3, etc.

This would be such a win over a new pragma that it's potentially a good 
idea to enable C++11 attributes in C and other language standards to get 
this. It solves entire chunks of the specification and implementation 
questions posed in this thread.

If we went that way, portable usage would still be easily achieved with 
a wrapper macro that gets defined away on incompatible compilers. In 
fact it'd be easier to make portable than code using a pragma.

I suspect the written form would be more logical as it's clear which 
loop the attributed statement applies to, and the AST representation / 
template instantiation would be handled for us.

The downside I can see to this proposal is that Objective-C would 
require disambiguation not only in C++ mode but also C if such a change 
were made. Perhaps we can define a macro-like compatibility wrapper in C 
mode..

I'll think about this a bit more and see if it's viable. Very smart idea 
from Aaron if we can make it work in some form.

Alp.


>
>   -Hal
>
>> ~Aaron
>>

-- 
http://www.nuanti.com
the browser experts