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?
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.
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.
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*).
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++.
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.
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
Should it be__attribute__((align(32)))?
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 ...
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.
Thank you for clarifying!