John Regehr <reg...@cs.utah.edu> writes: > See here: > > http://embed.cs.utah.edu/embarrassing/ > > There is a lot of data there. Please excuse bugs and other > problems. Feedback would be appreciated. >
I was a bit surprised by the icc results, because traditionally icc doesn't have a good reputation for good code size (and for my own testing icc output is usually larger). So I took a look at some of these. Some of the test cases seem very broken. For example the first 1000% entry here http://embed.cs.utah.edu/embarrassing/dec_09/harvest/gcc-head_icc-11.1/ int fetchBlock (INDATA * in, char *where, int many) { int copy; int advance; int i; int tmp; { advance = 1; i = 0; while (i < copy) "copy" is clearly uninitialized. So how can this function ever have worked? Depending what's on the stack or in a register it'll corrupt random memory. icc wins because it assumes uninitialized variables are 0 and optimizes away everything. I wonder if the original program was already broken or was this something your conversion introduced? it might be a good idea to check for unitialized variable warnings and remove completely broken examples (unfortunately the gcc uninitialized variables warnings are not 100% accurate) Looking further down the table a lot of the differences on empty-after-optimization functions (lots of 5 vs 2 bytes) seem to be that gcc-head uses frame pointers and the other compiler doesn't. Clearly for a fair comparison these settings should be the same. -Andi
