[cfe-dev] Adding a new pragma to Clang

[Hal Finkel]

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

Regarding memory access independence, we should also not tie this to the vectorizer. It can be used by alias analysis and affect many other things. It is true that taking Intel's ivdep, or similar, may have a lot of semantic baggage that we don't want, but having a syntax which specifically says 'safe for vectorization' may be too strong for cases where vectorization itself is not at issue. At the C++ standards committee meeting in Chicago, we discussed this issue somewhat (in the context of some parallelization/vectorization proposals), and I believe that we settled on the term 'unsequenced' to describe the semantics we'd like here. I think adopting that makes sense. Maybe something like:

#pragma loop unsequenced
or
#pragma loop_unsequenced
or just
#pragma unsequenced

And while you're right that people need to ifdef their code anyway for some things, we should not make it more difficult than necessary. If the syntax adopted by other vendors is not horrid, and has the semantics we desire, then we should follow the trend.

 -Hal

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

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