"John Matthews" <jm5...@...> wrote: > "John Matthews" <jm5678@> wrote: > > "peternilsson42" <peternilsson42@> wrote: > > > > > > However main() is > > > optimised effectively to a no-op since the compiler > > > was able to recognise that foo(i) will indeed equal > > > bar(i) for the iterated values of i! > > > > I'm not disputing the evidence, but I'm very surprised > > it can go that far. I wonder how many other functions > > (besides pow()) it 'knows' about?
Quite a few. But even if it doesn't, there are several layers of optimisers in modern implementations. So, even if the compiler only really understood pow as a simple inline assembly instruction, an assembler optimiser may be able to use its knowledge of that instruction. Modern optimisers are pretty freaky and even the people who write them aren't always sure which path their optimisers will take with a given piece of code. :-) > And if it's clever enough to optimise out the calls to > the functions, why still generate the code for them? > I would have thought that recognising that they're > unused would be relatively simple. It is, but it's left to the linker. Compilers can't assume what the linker will be asked to do. It can't assume, by default, that main will be the start up function, or that a function with external linkage will not be called elsewhere at start up (e.g. static object initialisation in C++,) or that the object module won't be turned into a library with main removed, etc... -- Peter
