gnupic: Thread: Linker Optimizations

I've always been frustrated about some big optimizations that can only be made manually; the linker doesn't seem to have enough information to optimize them.  HI-TECH will avoid these issues by using "omnicode", meaning all source files are compiled at the same time, and SourceBoost seems to skirt the problem with a custom object file format.  The two that stand out to me are:
 a) code-flow-related optimizations on page and bank selections
 b) removal of unused functions and global variables

Pages and Banks
The first would probably have a very noticeable effect, especially on MCU's with many banks and pages, or on modular code with many separate sections.  However, control-flow information would have to be passed from the compiler to the linker, and there may not be a convenient and portable mechanism for it.  Some flow information can be obtained directly from the asm/machine code, but I've experimented some and found jump tables and bank/page side-effects to be major issues there.

Unused Symbols
The second one would almost be possible.  One scheme would be to place each function and variable in its own relocatable section, and then ignore each section with no symbols externally accessed.  However, this scheme would bloat the code with page/bank selection unless the first optimization were also used.

A more practical solution would be to flag (at compile/assembly time) each symbol not used internally by its module, and keep track of the size of the function/variable for each symbol.  At link time, each unreferenced symbol and its corresponding allocation could be ignored.  This would also require some additions to the compiler->linker communication (object file or related).

Notice that the only real difference between these two schemes is that the second ensures allocation in the same bank/page.  Additions to the lkr file format itself might help some, but the compiler probably shouldn't touch the lkr file.


I know that compatibility and the separation of compiling and linking in general place a lot of restrictions on how the build system can and should work, but I also find it very frustrating that I can know all of the necessary information in advance to make more code fit on my tiny MCU's and still not have the means to do it.  Separate objects are very useful when you need them, but they cause a lot of overhead on MCU's when you don't.

Would it be a good idea to allow a "compilation-at-once" option similar to HI-TECH's so that users had the choice to take advantage of compiler/assembler->linker communication?  Alternatively, would it work to create optional extra files to extend the object file (such as control-flow-graph information) that could be enabled to pass more information along to the linker?  One of these features could help somewhat with support in the assembler, but the real power would be in compiler support since pages and banks are irrelevent to the HLL source code.

There are some additional optimizations and other benefits that these suggestions would allow for, but I'll save the details for later.

Thoughts?

David
(P.S. sorry for the rant, these ideas have been festering a while)