[cfe-dev] Adding a new pragma to Clang

[Hal Finkel]

----- 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.

 -Hal

> 
> ~Aaron
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory