[cfe-dev] Adding a new pragma to Clang
Aaron Ballman
aaron at aaronballman.com
Wed Jan 8 06:22:18 PST 2014
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.
~Aaron
More information about the cfe-dev
mailing list