Did anybody do some metrics how big the savings would be?
I think we should loom at the metrics before jumping to
conclusions about implementing such a feature.
On Sep 20, 2006, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 20, 2006 at 02:52:40AM -0300, Alexandre Oliva wrote:
>> For extra bonus points, it may short-circuit relocations that call foo
>> (as opposed to taking its address) when it binds locally and skip the
>> jmp altogether. Ditto for
On Wed, Sep 20, 2006 at 02:52:40AM -0300, Alexandre Oliva wrote:
> The linker already has code to merge sections. There's nothing to
> stop us from compiling every function into say:
>
> foo:
> jmp .foo.impl
> .section .gnu.impl.foo, "axM"
> .foo.impl:
> [actual code for foo emitted]
> .previ
On Sep 18, 2006, Roman Kononov <[EMAIL PROTECTED]> wrote:
> Merge can be safely done like this:
> If both functions A and B are not inlined functions, and they have
> single entry points, and memcmp of their asm code is zero, and the
> code is large enough, then the asm code of the functions B is
Daniel Berlin writes
>Please go away and stop trolling.
I'm not the one who's being rude and abusive.
>If your concern is function pointers or global functions, you can
>never eliminate any global function, unless your application doesn't
>call dlopen, or otherwise load anything dynamically, incl
On Sep 18, 2006, at 4:17 PM, Jed Davis wrote:
As a convenient side-effect, setting breakpoints on only one variant
will also still work.
Well, not quite. For it to work nicely, you'd want the jmp version,
and you'd want to defeat the gdb set breakpoint after prologue logic,
and even then,
On Mon, Sep 18, 2006 at 12:09:36PM -0700, Mark Mitchell wrote:
> Mike Stump wrote:
> >On Sep 15, 2006, at 2:32 PM, Ross Ridge wrote:
> >>Also, I don't think it's safe if you merge only functions in COMDAT
> >>sections.
> >
> >Sure it is, one just needs to merge them as:
> >
> >variant1: nop
> >var
Mike Stump <[EMAIL PROTECTED]> writes:
> On Sep 15, 2006, at 2:32 PM, Ross Ridge wrote:
>> Also, I don't think it's safe if you merge only functions in COMDAT
>> sections.
>
> Sure it is, one just needs to merge them as:
>
> variant1: nop
> variant2: nop
> variant3: nop
> [ ... ]
>
> this wa
Mike Stump wrote:
On Sep 15, 2006, at 2:32 PM, Ross Ridge wrote:
Also, I don't think it's safe if you merge only functions in COMDAT
sections.
Sure it is, one just needs to merge them as:
variant1: nop
variant2: nop
variant3: nop
[ ... ]
this way important inequalities still work.
Yes,
On Sep 15, 2006, at 2:32 PM, Ross Ridge wrote:
Also, I don't think it's safe if you merge only functions in COMDAT
sections.
Sure it is, one just needs to merge them as:
variant1: nop
variant2: nop
variant3: nop
[ ... ]
this way important inequalities still work. This requires multi
On 09/15/2006 04:32 PM, Ross Ridge wrote:
Also, I don't think it's safe if you merge only functions in COMDAT
sections.
Consider:
#include
template T foo(T a) { return a; }
template T bar(T a) { return a; }
int
main() {
assert((int (*
>You can believe what you like about the idea. Until you are willing
>to implement something *you* believe will help, or at the least
>explain how you forsee it being done safely (which Microsoft
>doesn't!), it's very hard to take you seriously
As I've already said, it can be made safe by commu
Daniel Berlin writes
>Do you really want me to sit here and knock down every single one of
>your arguments?
Why would you think I would've wanted your "No, it isn't" responses
instead?
>Your functions you are trying to optimize for multiple cpu
>types and compiled with different flags may be outp
On 9/16/06, Ross Ridge <[EMAIL PROTECTED]> wrote:
Ross Ridge writes:
>Microsoft's implementation has proven that "stupid" byte comparions can
>generate significant savings.
Daniel Berlin wrtes:
>No they haven't.
So Microsoft and everyone who says they've got significant savings using
it is lyin
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
| > >No it can't. It has no idea what a function consists of other than a
| > >bunch of bytes, in pretty much all cases. ... Stupid byte
| > >comparisons of functions generally won't save you anything truly
| > >interesting.
| >
| > Microsoft's implemen
Ross Ridge writes:
>Microsoft's implementation has proven that "stupid" byte comparions can
>generate significant savings.
Daniel Berlin wrtes:
>No they haven't.
So Microsoft and everyone who says they've got significant savings using
it is lying?
>But have fun implementing it in your linker, an
>No it can't. It has no idea what a function consists of other than a
>bunch of bytes, in pretty much all cases. ... Stupid byte
>comparisons of functions generally won't save you anything truly
>interesting.
Microsoft's implementation has proven that "stupid" byte comparions can
generate signif
Gabriel Dos Reis write:
>Not very logn ago I spoke with the VC++ manager about this, and he
>said that their implementation currently is not conforming -- but
>they are working on it. The issue has to with f and f
>required to have difference addresses -- which is violated by their
>implementation
Ross Ridge <[EMAIL PROTECTED]> writes:
[...]
| >>I think this is best done by linker which
| >>can much more reliably compare the contents of functions to see if they
| >>are the same.
| >
| >No it can't. It has no idea what a function consists of other than a
| >bunch of bytes, in pretty much al
Ross Ridge writes:
>No, and I can't see how how you've came up with such an abusurd
>misintepretation of what I said. As I said clearly and explicity,
>the example I gave was where you'd want to use function merging.
Daniel Berlin writes:
>Whatever. Why would you turn on function merging if you
Daniel Berlin wrote:
Actually, even for non-POD types, it catches a lot of templatized
member functions that mainly depend on size (but they are still
container classes).
Just another ( maybe stupid :-) ) idea. What about "partial merge"?
static int x = 0;
void a()
{
printf( "aaa" );
x
Mark Mitchell wrote:
Anyhow, I think that a combination of compiler/linker help and
programmer help are useful. There are some cases where you can do this
automatically, and others where you might need programmer help. Just as
-ffast-math is useful, so might -fmerge-functions or
__attribute_
On 9/15/06, Ross Ridge <[EMAIL PROTECTED]> wrote:
Ross Ridge writes:
>I don't think this is a good idea. With different compiler options the
>same RTL can generate different assembly instructions. Consider the case
>of compiling the same function multiple times with different names and
>differ
Ross Ridge writes:
>I don't think this is a good idea. With different compiler options the
>same RTL can generate different assembly instructions. Consider the case
>of compiling the same function multiple times with different names and
>different CPU architectures selected. You'd actually want
On 9/15/06, Ross Ridge <[EMAIL PROTECTED]> wrote:
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.
I don't think this is a good idea. With different compiler options the
same RTL can ge
Laurent GUERBY wrote:
On Fri, 2006-09-15 at 13:54 -0700, Ian Lance Taylor wrote:
Laurent GUERBY <[EMAIL PROTECTED]> writes:
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
On Fri, 2006-09-15 at 13:54 -0700, Ian Lance Taylor wrote:
> Laurent GUERBY <[EMAIL PROTECTED]> writes:
> > 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 identi
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.
I don't think this is a good idea. With different compiler options the
same RTL can generate different assembly instructions. Consider th
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 CO
It seems to me that most candidates for merging that could be
eliminated by this approach are of the form
std::container::some_method(...)
Actually, even for non-POD types, it catches a lot of templatized
member functions that mainly depend on size (but they are still
container classes).
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
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 wh
On 9/15/06, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
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, bu
On 9/15/06, Michael Popov <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
> There are of course, collisions possible in the hash, and in the
> absolute worst case, it is possible to end up with no warning but
> wrong results. In particular, if you get a collision and the length
> of the function
Daniel Berlin wrote:
There are of course, collisions possible in the hash, and in the
absolute worst case, it is possible to end up with no warning but
wrong results. In particular, if you get a collision and the length
of the functions happens to be the same, i don't believe the linker
will com
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 perm
On 15 Sep 2006 09:27:32 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
> Isn't this what you describe here the same as COMDAT?
Not exactly. COMDAT means that the compiler can generate multiple
instances of, say, the list functions, and only one
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
> Isn't this what you describe here the same as COMDAT?
Not exactly. COMDAT means that the compiler can generate multiple
instances of, say, the list functions, and only one version will
be included in the final executable. However, if you use both
Steven Bosscher wrote:
Isn't this what you describe here the same as COMDAT?
Well, MS VC have an option "enable COMDAT folding" - which
turns ON merging of identical functions.
BTW, this is linker option... should it be addressed to GCC's LTO?
I'm not sure if function body is equivalent to "COM
Hi,
Isn't this what you describe here the same as COMDAT?
Gr.
Steven
On 9/15/06, Michael Popov <[EMAIL PROTECTED]> wrote:
Hello!
There is very good blog post about the problem:
http://vladimir_prus.blogspot.com/2005/03/duplicate-function-bodies.html
> A couple of days ago I've learned that
40 matches
Mail list logo
