- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
Link Copied
10 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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++.
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++.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Should it be
__attribute__((align(32)))
?
__attribute__((align(32)))
?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for clarifying!

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page