On 15 Sep 2006 13:54:00 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Laurent GUERBY <[EMAIL PROTECTED]> writes:> On Fri, 2006-09-15 at 09:27 -0700, Ian Lance Taylor wrote: > > I think Danny has a 75% implementation based on hashing the RTL for a > > section and using that to select the COMDAT section signature. Or the > > hashing can be done in the linker, but it still needs compiler help to > > know when it is permissible. > > For code sections (I assume read-only), isn't the linker always able to > merge identical ones? What can the compiler do better than the linker? The linker can't merge just any identical code section, it can only merge code sections where that is permitted. For example, consider: int foo() { return 0; } int bar() { return 0; } int quux(int (*pfn)()) { return pfn == &foo; } Compile with -ffunction-sections. If the linker merges sections, that program will break. I think that in general it would be safe to merge any equivalent COMDAT code section, though.
Just like most other compiler optimizations, as-if rule would apply here as well. If the linker can fake the above or prevent the optimization to happen only for above cases, the optimization can be safe (e.g. if there's no relocation against the function other than direct call and the function symbol is "hidden" (as in linker scoping), the linker can know that the address of a function is not taken). However, I'd like to note that the debug information could become screwy under this optimization (as usual with any optimization of this sort) and could potentially make debugger's life somewhat miserable (e.g. a template of a pointers may end up having exactly the same code thus eligible for merging by linker, then debugger may not be able to tell what is the real type of the pointer, and you'll get "impossible" stack traces, etc). -- #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
