From: "Arnold Schwaighofer" <firstname.lastname@example.org>
To: "Hal Finkel" <email@example.com>
Cc: "Alp Toker" <firstname.lastname@example.org>, "Richard Smith" <email@example.com>, "Clang Dev" <firstname.lastname@example.org>, "Renato
Golin" <email@example.com>, "Nadav Rotem" <firstname.lastname@example.org>
Sent: Tuesday, January 7, 2014 5:19:26 PM
Subject: Re: [cfe-dev] Adding a new pragma to Clang
>> From: "Alp Toker" <email@example.com>
>> To: "Renato Golin" <firstname.lastname@example.org>, "Hal Finkel"
>> Cc: "Richard Smith" <email@example.com>, "Clang Dev"
>> Sent: Monday, January 6, 2014 9:42:01 AM
>> Subject: Re: [cfe-dev] Adding a new pragma to Clang
>>> 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
>>> does what we need in IR in the long run: lexical block level
>> The C frontend syntax is the one that's going to ship and get used
>> tens of thousands of software projects, and which we might still
>> having to support 15 years later when the CPU architectures have
>> changed. It's quite likely in that lifetime that other vendors
>> 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:
> IBM's compiler also has a few of these (unroll, novector, etc.):
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
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.