I had this happen long time ago when I included the different object files or libraries in the wrong order with GCC under linux. After reordering them so that their contend had already been referenced, all was well. I think I had similar problems (immediately solved) with mspgcc. If these compiler flags allow treating different functions in the same files to be kept or discarded depending of whether they are used, it's obvious that they need to be be considered unused when they haven't been referenced yet. (It would be pretty useless to have such a feature if it could be inhibited by circular references of dead code.) Unless the linker has been greatly improved since then, the problem should be there. Maybe I'm wrong.
About the reduced effectiveness of the optimization, this one is obvious. If the linker is allowed to include or discard parts of a compilation unit depending of their usage, the compiler may not do any optimization that crosses the boundary between functions. Else either common code may disappear when not linked or a reference is generated that will keep the normally unused other function from being excluded from the build. Or the common part is referenced by both with a branch (instead of a relative jump), making the code less efficient. Also, some addressing modes cannot be used under such a setup. Optimizations INSIDE a function are not touched, of course. Only those across functions (e.g. identical exit code). The common subexpression elimination was a bad example. (I was a bit in haste when I wrote this, it was at the end of my office hours) JMGross ----- Ursprüngliche Nachricht ----- Von: Grant Edwards An: [email protected] Gesendet am: 15 Jun 2010 20:26:25 Betreff: Re: [Mspgcc-users] Unused functions occupying unnecessary memory On 2010-06-15, JMGross <[email protected]> wrote: > The suggested compiler/linker flags, however, let the compiler treat > each function as a separate compilation unit, starting at its own > 0-offset address. This means teh compiler will not resolve any local > references and let it all to the linker. Since all references are > passed to the linker, the linker can link or discard every of these > sections depending on the open references. What's references from a > different module is kept, what's not referenced will be discarded. > But it may happen that parts are discarded bwcause not yet referenced > by any of the already loaded modules, bu twill be later and then the > reference cannot be resolved as the target had been discarded > already. If that happens, it's a bug. Can you post an example of that so it can be fixed? > Also, it keeps the compiler for doing optimizations like common > subexpression elimination or using the most efficient way to call > functions or access variables, as they are all referenced as > externals. I'd also be interested in seeing examples of that.
