How to trick C/C++ compilers into generating terrible code?
futurechips.org
How to trick C/C++ compilers into generating terrible code?
1–10 of 19 posts
Re: How to trick C/C++ compilers into generating terrible code?
#2Interesting point about ICC generating faster code and the link order making a difference in the running time of the application.
Re: How to trick C/C++ compilers into generating terrible code?
#3Although it's a poorly titled article, it was interesting to read. Surely the objective is to trick the compiler into generating the best code. I was surprised that the vectorisation it mentions was not performed automatically.
One other way would be to target different hardware than it's designed to work with via flags, or by using AMD with the intel compiler mentioned in the article. There was a very short discussion about this on reddit yesterday http://www.reddit.com/r/programming/comments/lj1ze/ask_rprog...
Re: How to trick C/C++ compilers into generating terrible code?
#4These issues are why various compiler hints exist.
In the dead code example, the gcc function attribute 'const' can be applied to the declaration of bar(), telling the compiler that it is a pure function whose result depends on nothing but its arguments.
In the pointer example, the C99 standard 'restrict' qualifier can be applied to a, b and c to tell the compiler that the values pointed to by these variables do not overlap.
'restrict' will also help the global variable example - the reason that N is loaded each time around the loop is because as far as the compiler knows, one of the a[i]s could alias with N.
Re: How to trick C/C++ compilers into generating terrible code?
#5Although it's a poorly titled article, it was interesting to read. Surely the objective is to trick the compiler into generating the best code. I was surprised that the vectorisation it mentions was not performed automatically. One other way would be to target different hardware than it's designed to work with via flags, or by using AMD with the intel compiler mentioned in the article. There was a very short discussi…
Depends entirely upon the compiler. Don't worry about this stuff in general unless you're doing embedded work, where the compilers are often problematical. Any desktop compiler will know more about generating code than you do.
Re: How to trick C/C++ compilers into generating terrible code?
#6Interesting point about ICC generating faster code and the link order making a difference in the running time of the application.
The biggest thing you'll notice in practice from ICC is that it is much more likely to unroll a loop and transform the body to use SSE instructions when requested. If you have dense numeric code and aren't either using ICC or hand-unrolling and using GCC intrinsics, you're probably leaving performance on the floor.
But, there's still no free lunch. For example, as of about two months ago, ICC will unroll loops whose increment is "i++" but will not unroll loops whose increment is "i+=1". Some insight, looking at output assembly, etc. is still required.
Re: How to trick C/C++ compilers into generating terrible code?
#7These issues are also why sql hints exist.
Re: How to trick C/C++ compilers into generating terrible code?
#8Although it's a poorly titled article, it was interesting to read. Surely the objective is to trick the compiler into generating the best code. I was surprised that the vectorisation it mentions was not performed automatically. One other way would be to target different hardware than it's designed to work with via flags, or by using AMD with the intel compiler mentioned in the article. There was a very short discussi…
Depends entirely upon the compiler. Don't worry about this stuff in general unless you're doing embedded work, where the compilers are often problematical. Any desktop compiler will know more about generating code than you do.
Embedded compilers are perfectly intelligent; I would hazard that you just wind up doing weird things more often, and/or you care more what exactly it does with this or that function because of your 32kHz clock and/or 1KB of program memory.
Re: How to trick C/C++ compilers into generating terrible code?
#9These issues are why various compiler hints exist. In the dead code example, the gcc function attribute 'const' can be applied to the declaration of bar(), telling the compiler that it is a pure function whose result depends on nothing but its arguments. In the pointer example, the C99 standard 'restrict' qualifier can be applied to a, b and c to tell the compiler that the values pointed to by these variables do not…
Mild quibble: the attribute you want is "pure", not "const". The distinction is that a const function inspects nothing but its arguments, but a pure function is allowed to read (but not write) external memory. Both are without side effects and can be optimized out of loops, but pure is looser. Not all const functions can be pure.
Re: How to trick C/C++ compilers into generating terrible code?
#10Although it's a poorly titled article, it was interesting to read. Surely the objective is to trick the compiler into generating the best code. I was surprised that the vectorisation it mentions was not performed automatically. One other way would be to target different hardware than it's designed to work with via flags, or by using AMD with the intel compiler mentioned in the article. There was a very short discussi…
> I was surprised that the vectorisation it mentions was not performed automatically.
The OP didn't mention what compiler was being used; GCC will certainly automatically vectorize this example (and ICC probably will as well). I used GCC 4.4 for x86 with -O3 -msse2.
Of course, there's a lot of compensation code inserted for unaligned pointers and aliased pointers and the like, but automatic vectorization is certainly doable.