On Mon, Dec 14, 2009 at 09:30:57AM -0700, John Regehr wrote: > I also noticed these testcases but decided to leave them in for now. > Obviously the code is useless, but it can still be interpreted according to > the C standard, and code can be generated. Once you start going down the > road of exploiting undefined behavior to create better code -- and gcc > already does this pretty aggressively -- why not keep going?
I'm not sure relying on uninitialized variables for optimization is a good idea. > That said, if there's a clear sentiment that this kind of test case is > undesirable, I'll make an effort to get rid of these for subsequent runs. > The bottom line is that these results are supposed to provide you folks > with useful directions for improvement. I personally feel that test cases that get optimized away are not very interesting. > >> 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. > > I wanted to avoid playing flag games and go with -Os (or nearest > equivalent) for all compilers. Maybe that isn't right. At least for small functions this skews the results badly I think. On larger functions it would be less a problem. On my gccs on linux actually no frame pointer is the default, but that might depend on the actual target configuration it was built for. I think that default was changed at some point and it also depends on the OS. -Andi -- a...@linux.intel.com -- Speaking for myself only.
