Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.
7944 Discussions

is __restrict a valid qualifier or only restrict?

Azua_Garcia__Giovann
968 Views
Hello again,

Is "__restrict" the right qualifier also for the Intel compiler? will it work? or do I have to use just "restrict" along with the -restrict compiler option?

TIA,
Best regards,
Giovanni
0 Kudos
10 Replies
Georg_Z_Intel
Employee
968 Views
Hello Giovanni,

the correct use is to go with the "restrict" as keyword. If you're using anything else than C99 (the only one this keyword is specified for) you have to supply the "-restrict" (Linux* or Mac OS* X) or "/Qrestrict" (Windows*) option to enable it.

The "__restrict" & "__restrict__" keywords are mostly internal and should not be used. However, they still work even without supplying any additional compiler option.

Best regards,

Georg Zitzlsberger
0 Kudos
Azua_Garcia__Giovann
968 Views
Hi Georg,

Thank you for clarifying! :)

What do you mean by:

"The "__restrict" & "__restrict__" keywords are mostly internal and should not be used. However, they still work even without supplying any additional compiler option."

works means it compiles fine or works means it will provide the appropriate restrict hint to the compiler?

I know it compiles fine with it, what I am asking is whether it is going to have an effect in hinting that there are no other pointers to that location.

TIA,
Best regards,
Giovanni
0 Kudos
Georg_Z_Intel
Employee
968 Views
Hello Giovanni,

all those keywords work the same for Intel® C++ Compiler. However, the internal versions are least portable and hence not recommended.

So, whatever version you use you tell the compiler that pointers are not overlapping (more precisely their targets) - there are no other pointers to that location, as you say.

Edit:
Another point that might be interesting for you, esp. when using the "restrict" keyword:
Our Intel® C++ Compiler does not enable strict aliasing by default. So, if you're looking for performance and have ANSI compliant code you for sure also want to turn on "-ansi-alias" (Linux* & Mac OS* X) or "/Qansi-alias" (Windows*).

Best regards,

Georg Zitzlsberger
0 Kudos
TimP
Honored Contributor III
968 Views
Microsoft has documented for several years the __restrict spelling.  However, I haven't found any use for it in MSVC (it doesn't even pass syntax checking).  It has the desired effect in Intel compilers, and in gcc/g++ (on many targets).
The documentation on how portable this more widely used spelling may be for C++ is lacking, in my opinion.  I don't see whether Georg would recommend the spelling which is acceptable to multiple compilers, or the use of #define macros to change among compilers.  The latter seem better between MSVC and ICL.

Georg's point about setting -ansi-alias for Intel compilers (to get the equivalent of the gcc rather than Microsoft default) is a valid one.

Both ansi-alias option and restrict/__restrict are inherent in CEAN notation, so that provides an alternative way (of limited portability) to get those optimizations.  I don't know if this means we are on shaky ground if we use CEAN in cases of possible data overlap.  CEAN is marketed as part of the Cilk+ extension set for C or C++.  Cilk+ introduces a few more somewhat obscure differences between C (C99 preferred) and C++.
0 Kudos
jeff_keasler
Beginner
968 Views
As an aside, issue #672743 has been tested, and allows you to do this:

    typedef double * __restrict__ __attribute__((align_value (32))) Real_ptr ;

Creating such a typedef in a header file allows vectorization without cluttering your core code with compiler directives and restrict keywords.

Fixing issue 682457 would extend the scope where these optimizations apply.
0 Kudos
Azua_Garcia__Giovann
968 Views
Hi,

I am trying to use your suggested typedef and get the following warning:

/Users/bravegag/code/fastcode_project/code/src/support/utils.h(30): warning #1292: unknown attribute "align_value"
  typedef double * __restrict__ __attribute__((align_value (32))) double_aptr32;

I am using the compiler beta 13 update 2 version.

Many TIA,
Best regards,
Giovanni
0 Kudos
TimP
Honored Contributor III
968 Views
Should it be
__attribute__((align(32)))
?
0 Kudos
Azua_Garcia__Giovann
968 Views
Hi TimP,

Are you asking me? :D

Actually I put "aligned" and "align" and the compiler does not complain ... it is a bit confusing with all the variations of these keywords whether I'm using the right one or more importantly if the compiler is getting to do what I intend it to ...

Best,
Giovanni
0 Kudos
TimP
Honored Contributor III
968 Views
I hope the documentation is only preliminary.  The spelling __declspec(align(32)) is documented there.
Clearly, there have been urgent requests to support also the documented gcc spelling  __attribute__((aligned(32))) (on both linux and Windows).  I  hope that version was tested.
I agree entirely that the subject should not be confused with new spellings when there are already working Microsoft and gcc spellings for this feature.
0 Kudos
Azua_Garcia__Giovann
968 Views
Thank you for clarifying!
0 Kudos
Reply