Re: EGCS: pointer to member functions.

Re: EGCS: pointer to member functions.

[Mike Stump]

> From: Alexandre Oliva <oliva@dcc.unicamp.br>
> Date: 17 Jun 1999 03:17:15 -0300

> On Jun 16, 1999, mrs@wrs.com (Mike Stump) wrote:

> It seems to me that a pair<pointer_to_thunk,offset> is fast and
> general enough, but generating specialized thunks could save us
> space.  Do you think it is worth it?

No, not at this point in time.  I would rather see other bugs fixed
personally.

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 17, 1999, mrs@wrs.com (Mike Stump) wrote:

>> From: Alexandre Oliva <oliva@dcc.unicamp.br>

>> It seems to me that a pair<pointer_to_thunk,offset> is fast and
>> general enough, but generating specialized thunks could save us
>> space.  Do you think it is worth it?

> No, not at this point in time.  I would rather see other bugs fixed
> personally.

Ok, here's a new entry for the projects page, as you had suggested.
Ok to install?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Gerald Pfeifer]

On 21 Jun 1999, Alexandre Oliva wrote:
> Ok, here's a new entry for the projects page, as you had suggested.
> Ok to install?

Okay from my side, if Mike or one of our C++ maintainers agrees with the
contents, though I recommend against using "here" as link description.

How about "as described by Some Name" or similiar instead?

Thanks!
Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 21, 1999, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:

> On 21 Jun 1999, Alexandre Oliva wrote:
>> Ok, here's a new entry for the projects page, as you had suggested.
>> Ok to install?

> Okay from my side, if Mike or one of our C++ maintainers agrees with the
> contents, though I recommend against using "here" as link description.

Ok, I changed the link text to `the one discussed in the
mailing-list'.

I'll wait for input from Mike and Martin before installing it.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Jason Merrill]

I'm really don't think this change is a good idea; going through a thunk
costs more than a simple test.  With branch prediction, the cost of the
test is about zero, while the thunk adds an extra jump.  This idea should
not go into projects.html.

The only reason to use thunks is to avoid paying for MI in single
inheritance code; for code that actually needs adjustments, offsets in the
vtable are a faster solution on modern architectures.  Which solution you
choose for calling virtual functions depends on how you view the tradeoff.

Jason

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 22, 1999, Jason Merrill <jason@cygnus.com> wrote:

> I'm really don't think this change is a good idea; going through a thunk
> costs more than a simple test.  With branch prediction, the cost of the
> test is about zero, while the thunk adds an extra jump.

But the thunk would only be used for
pointer-to-virtual-member-function.  With the current code, users are
paying the price of an additional test and branch even when they only
use pointer-to-non-virtual-member-function.

Moreover, even if the test cost is close to zero, it would still have
to branch, and, given that the `thunk' I have in mind is as simple as
a `trampoline', I don't see how it could be less efficient than the
current approach.  Only if branches with good prediction were much
cheaper than a 100% certain jump; is this the case?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Jason Merrill]

>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

 > On Jun 22, 1999, Jason Merrill <jason@cygnus.com> wrote:
 >> I'm really don't think this change is a good idea; going through a thunk
 >> costs more than a simple test.  With branch prediction, the cost of the
 >> test is about zero, while the thunk adds an extra jump.

 > But the thunk would only be used for
 > pointer-to-virtual-member-function.  With the current code, users are
 > paying the price of an additional test and branch even when they only
 > use pointer-to-non-virtual-member-function.

If the class has virtual functions, yes.

 > Moreover, even if the test cost is close to zero, it would still have
 > to branch, and, given that the `thunk' I have in mind is as simple as
 > a `trampoline', I don't see how it could be less efficient than the
 > current approach.  Only if branches with good prediction were much
 > cheaper than a 100% certain jump; is this the case?

So I'm told.  I must admit that I don't really understand the situation
myself.

Jason

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 23, 1999, Jason Merrill <jason@cygnus.com> wrote:

>>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

>> Moreover, even if the test cost is close to zero, it would still have
>> to branch, and, given that the `thunk' I have in mind is as simple as
>> a `trampoline', I don't see how it could be less efficient than the
>> current approach.  Only if branches with good prediction were much
>> cheaper than a 100% certain jump; is this the case?

> So I'm told.  I must admit that I don't really understand the situation
> myself.

Even if the branch is followed by a jump?  That's weird...  But now I
see there are cache issues too, and using a trampoline certain doesn't 
contribute to locality of code :-(

Well, I could add this point to the project, implying that it may end
up not being useful in general (although it might be on some
architectures), or just wipe it out.

I guess you'll just tell me to forget about it, but, just in case,
I'll wait for your input :-)

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Richard Henderson]

On Wed, Jun 23, 1999 at 03:13:58AM -0300, Alexandre Oliva wrote:
> Moreover, even if the test cost is close to zero, it would still have
> to branch, and, given that the `thunk' I have in mind is as simple as
> a `trampoline', I don't see how it could be less efficient than the
> current approach.  Only if branches with good prediction were much
> cheaper than a 100% certain jump; is this the case?

Indirect branches are often not predicted at all, and are typically
horrible for performance.  Most every target besides ia32 and m68k
would need to use an indirect branch in the thunk because a pc-relative
branch won't reach.


r~

Re: EGCS: pointer to member functions.

[Gerald Pfeifer]

On 21 Jun 1999, Alexandre Oliva wrote:
> Ok, here's a new entry for the projects page, as you had suggested.
> Ok to install?

Okay from my side, if Mike or one of our C++ maintainers agrees with the
contents, though I recommend against using "here" as link description.

How about "as described by Some Name" or similiar instead?

Thanks!
Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: EGCS: pointer to member functions.

[Jason Merrill]

>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

 > On Jun 22, 1999, Jason Merrill <jason@cygnus.com> wrote:
 >> I'm really don't think this change is a good idea; going through a thunk
 >> costs more than a simple test.  With branch prediction, the cost of the
 >> test is about zero, while the thunk adds an extra jump.

 > But the thunk would only be used for
 > pointer-to-virtual-member-function.  With the current code, users are
 > paying the price of an additional test and branch even when they only
 > use pointer-to-non-virtual-member-function.

If the class has virtual functions, yes.

 > Moreover, even if the test cost is close to zero, it would still have
 > to branch, and, given that the `thunk' I have in mind is as simple as
 > a `trampoline', I don't see how it could be less efficient than the
 > current approach.  Only if branches with good prediction were much
 > cheaper than a 100% certain jump; is this the case?

So I'm told.  I must admit that I don't really understand the situation
myself.

Jason

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 23, 1999, Jason Merrill <jason@cygnus.com> wrote:

>>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

>> Moreover, even if the test cost is close to zero, it would still have
>> to branch, and, given that the `thunk' I have in mind is as simple as
>> a `trampoline', I don't see how it could be less efficient than the
>> current approach.  Only if branches with good prediction were much
>> cheaper than a 100% certain jump; is this the case?

> So I'm told.  I must admit that I don't really understand the situation
> myself.

Even if the branch is followed by a jump?  That's weird...  But now I
see there are cache issues too, and using a trampoline certain doesn't 
contribute to locality of code :-(

Well, I could add this point to the project, implying that it may end
up not being useful in general (although it might be on some
architectures), or just wipe it out.

I guess you'll just tell me to forget about it, but, just in case,
I'll wait for your input :-)

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Mike Stump]

> From: Alexandre Oliva <oliva@dcc.unicamp.br>
> Date: 17 Jun 1999 03:17:15 -0300

> On Jun 16, 1999, mrs@wrs.com (Mike Stump) wrote:

> It seems to me that a pair<pointer_to_thunk,offset> is fast and
> general enough, but generating specialized thunks could save us
> space.  Do you think it is worth it?

No, not at this point in time.  I would rather see other bugs fixed
personally.

Re: EGCS: pointer to member functions.

[Richard Henderson]

On Wed, Jun 23, 1999 at 03:13:58AM -0300, Alexandre Oliva wrote:
> Moreover, even if the test cost is close to zero, it would still have
> to branch, and, given that the `thunk' I have in mind is as simple as
> a `trampoline', I don't see how it could be less efficient than the
> current approach.  Only if branches with good prediction were much
> cheaper than a 100% certain jump; is this the case?

Indirect branches are often not predicted at all, and are typically
horrible for performance.  Most every target besides ia32 and m68k
would need to use an indirect branch in the thunk because a pc-relative
branch won't reach.


r~

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 22, 1999, Jason Merrill <jason@cygnus.com> wrote:

> I'm really don't think this change is a good idea; going through a thunk
> costs more than a simple test.  With branch prediction, the cost of the
> test is about zero, while the thunk adds an extra jump.

But the thunk would only be used for
pointer-to-virtual-member-function.  With the current code, users are
paying the price of an additional test and branch even when they only
use pointer-to-non-virtual-member-function.

Moreover, even if the test cost is close to zero, it would still have
to branch, and, given that the `thunk' I have in mind is as simple as
a `trampoline', I don't see how it could be less efficient than the
current approach.  Only if branches with good prediction were much
cheaper than a 100% certain jump; is this the case?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 21, 1999, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:

> On 21 Jun 1999, Alexandre Oliva wrote:
>> Ok, here's a new entry for the projects page, as you had suggested.
>> Ok to install?

> Okay from my side, if Mike or one of our C++ maintainers agrees with the
> contents, though I recommend against using "here" as link description.

Ok, I changed the link text to `the one discussed in the
mailing-list'.

I'll wait for input from Mike and Martin before installing it.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 17, 1999, mrs@wrs.com (Mike Stump) wrote:

>> From: Alexandre Oliva <oliva@dcc.unicamp.br>

>> It seems to me that a pair<pointer_to_thunk,offset> is fast and
>> general enough, but generating specialized thunks could save us
>> space.  Do you think it is worth it?

> No, not at this point in time.  I would rather see other bugs fixed
> personally.

Ok, here's a new entry for the projects page, as you had suggested.
Ok to install?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Jason Merrill]

I'm really don't think this change is a good idea; going through a thunk
costs more than a simple test.  With branch prediction, the cost of the
test is about zero, while the thunk adds an extra jump.  This idea should
not go into projects.html.

The only reason to use thunks is to avoid paying for MI in single
inheritance code; for code that actually needs adjustments, offsets in the
vtable are a faster solution on modern architectures.  Which solution you
choose for calling virtual functions depends on how you view the tradeoff.

Jason

Re: EGCS: pointer to member functions.

[Martin v. Loewis]

> Opinions?

Generating pointer-to-member thunks for all member functions seems
like a big overhead to me. In my experience, pointer-to-members are
infrequently used, not justifying the overhead. But then, I thought
that virtual bases are also infrequently used, until I saw the CORBA
Objects-by-value mapping ...

I'll throw some other alternatives into the discussion:

1. the thunk could receive another implicit parameter, which is the
   type_info of the static type of the target object. It could then
   cast this to the right type, and invoke the target method.

2. if code size is the problem, we don't have to do the
   pointer-to-member evaluation inline. It could be a libgcc
   function.  If course, that would not improve speed, only size -
   perhaps done with -Os only.
  
Regards,
Martin

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 15, 1999, Brendan Simon <brendan@dgs.monash.edu.au> wrote:

> Why is there so much overhead in calling a function via a pointer as
> apposed to calling it directly?

Pointer-to-methods don't know whether they point to virtual methods or
not, so the caller must have code for both cases.  Methinks this could
be improved by generating thunks that perform dynamic binding in the
case of invoking virtual methods, but maybe I'm missing something.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 16, 1999, mrs@wrs.com (Mike Stump) wrote:

>> From: Alexandre Oliva <oliva@dcc.unicamp.br>
>> Date: 16 Jun 1999 20:13:03 -0300

>> (or comparison would have to become much more complicated).

> Yes.  :-(  Comparisons can run slower, if dispatch is fast.

It seems to me that a pair<pointer_to_thunk,offset> is fast and
general enough, but generating specialized thunks could save us
space.  Do you think it is worth it?

I see a lot of complications in generating offset-thunks dynamically.
If a thunk is just tacked in front of another, a series of casts, such
as base-to-derived and derived-back-to-base would create a sequence of
thunks that just cancel each other.  So, instead of dumbly stacking
offset thunks, we'd have to look into any existing thunk, tell whether
it is an dispatcher thunk or an offset thunk, and combine with an
existing offset thunk.  Maybe the offset thunk could also be combined
with the dispatcher thunk.

In any case, we'd have to dynamically allocate space for these thunks;
unlink in the vtable-thunks case, they can't be stored in the stack
because the casted pointer-to-member may live longer than the current
stack frame.


A design that comes to my mind is to construct pointer-to-member
mapping tables that, given a dispatcher thunk of a base class (say,
its address, or an index based on the order of declaration of the
methods in the base class), return the dispatcher thunk for the
derived class, and another that performs the reverse mapping.  The
disadvantage of this scheme is that dispatcher thunks would have to be
instantiated for each member of the classes involved in the type-cast.
We could generate weak definitions for the base thunks, to save some
space.  But if the point of using offset thunks is to save space, I'm
not really sure it does, since we'd have to add all this garbage any
time a pointer-to-member typecast is found.  But then, it's all static
data, and, if you create a lot of pointers-to-methods, it may pay
off...

Opinions?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Mike Stump]

> Date: Tue, 15 Jun 1999 06:28:16 +0000
> From: Brendan Simon <brendan@dgs.monash.edu.au>
> To: egcs mailing list <egcs@egcs.cygnus.com>

> egcs-1.1.2 powerpc-linux-crosscompiler, RedHat 5.2 Linux.

> I decided that the FSM actions would be member funtions of an FSM
> class.  I had a look at the generated assembly and am quite
> astonished at the code that is generated.  Why is there so much
> overhead in calling a function via a pointer as apposed to calling
> it directly ?

Because 20 years from now, someone will reuse your code, and use
multiple inheritance and virtual member functions and other such neat
features and they will expect the code to just work.

A member function is not a C function, it is a proper superset.  If
you want just a simple function, use a static member function, and
pass it the this pointer as the first argument.

Welcome to C++.

Re: EGCS: pointer to member functions.

[Mike Stump]

> From: Alexandre Oliva <oliva@dcc.unicamp.br>
> Date: 15 Jun 1999 17:08:52 -0300

> you could take the address of an implicitly-defined non-virtual
> method that works just like a thunk.

Thanks, I think you've convinced me it might not be too hard to do
this.  In fact this might be a good `fix' to the existing thunk
vtables code.

Wanna edit it into the projects page?

Re: EGCS: pointer to member functions.

[Mike Stump]

> From: Alexandre Oliva <oliva@dcc.unicamp.br>
> Date: 16 Jun 1999 20:13:03 -0300

> (or comparison would have to become much more complicated).

Yes.  :-(  Comparisons can run slower, if dispatch is fast.
Comparisons are evil and bad style.

Re: EGCS: pointer to member functions.

[Martin v. Loewis]

> Thanks, I think you've convinced me it might not be too hard to do
> this.

So easily convinced? :-) So what about assignment of
pointer-to-member?

struct FOO
{    public :
        virtual void f1();
};

extern FOO foo;
void (FOO::*fp)();

struct dummy{int i;};
struct S:dummy,FOO{
        virtual void f1();
};

void (S::*x)();

int bar()
{
  S *s = new S;
  FOO *foo = s;
  fp = &FOO::f1;
  (s->*fp)();      // Thunk expects vtable at offset 0
  x=fp;
  (s->*x)();       // vtable is at offset 4
}

Regards,
Martin

Re: EGCS: pointer to member functions.

[Mike Stump]

> From: Alexandre Oliva <oliva@dcc.unicamp.br>
> Date: 15 Jun 1999 03:54:56 -0300

> On Jun 15, 1999, Brendan Simon <brendan@dgs.monash.edu.au> wrote:

> > Why is there so much overhead in calling a function via a pointer as
> > apposed to calling it directly?

> Pointer-to-methods don't know whether they point to virtual methods or
> not, so the caller must have code for both cases.  Methinks this could
> be improved by generating thunks that perform dynamic binding in the
> case of invoking virtual methods, but maybe I'm missing something.

Try it, lay it out, read up on C++ and what is required of the
generated code.  :-) I have, I think.  :-) Hint, there is no separate
type for pointer to virtual method and pointer to non-virtual member.
Now, complete program analysis and code complete generation at link
time trivially solves this problem.  This means that one could put the
info into the repo file, and just call a recompile pass for any files
that then don't meet the flexibility requirements.

But, I whimped out and did it the easy way.

Re: EGCS: pointer to member functions.

[Joe Buck]

> > Here we have to build a thunk (thunk(&fp,4)) ontop of the existing
> > thunk.
> 
> But then, it would have to be registered somewhere, to ensure
> uniqueness, otherwise pointer-to-members wouldn't compare equal when
> they should (or comparison would have to become much more
> complicated).

Comparing pointers to member functions for equality (for values other than
null) is a far rarer operation than assignment (I've never seen anyone do
it).  It would be appropriate to make assignment faster in exchange for
making comparison slower.

But the new design would have to support comparison, it seems.  Yuk.

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 15, 1999, mrs@wrs.com (Mike Stump) wrote:

>> From: Alexandre Oliva <oliva@dcc.unicamp.br>
>> Date: 15 Jun 1999 03:54:56 -0300

>> On Jun 15, 1999, Brendan Simon <brendan@dgs.monash.edu.au> wrote:

>> > Why is there so much overhead in calling a function via a pointer as
>> > apposed to calling it directly?

>> Pointer-to-methods don't know whether they point to virtual methods or
>> not, so the caller must have code for both cases.  Methinks this could
>> be improved by generating thunks that perform dynamic binding in the
>> case of invoking virtual methods, but maybe I'm missing something.

> Try it, lay it out, read up on C++ and what is required of the
> generated code.  :-) I have, I think.  :-) Hint, there is no separate
> type for pointer to virtual method and pointer to non-virtual member.

Yup, no problem.  You can decide what to do when the pointer is
created.  If the method is non-virtual, you can just take its address
directly.  If not, you could take the address of an implicitly-defined
non-virtual method that works just like a thunk.  This non-virtual
method could be handled just like template functions, in terms of
implicit instantiation, so I don't see a problem here.  Is there any
flaw in my reasoning?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

EGCS: pointer to member functions.

[Brendan Simon]

egcs-1.1.2 powerpc-linux-crosscompiler, RedHat 5.2 Linux.

I am implementing a finate state machine using a 2 dimensional array.  I
decided that the FSM actions would be member funtions of an FSM class.
I had a look at the generated assembly and am quite astonished at the
code that is generated.  Why is there so much overhead in calling a
function via a pointer as apposed to calling it directly ?  I'm not sure
why there are comparison statements (cmpwi).  The .cpp and .s files
follow.

--------------------------------------------

class FOO
{    public :
        void    f1();
};

extern FOO foo;
void (FOO::*fp)();  // pointer to FOO member function.

void direct()
{
    foo.f1();
}

void indirect()
{
    (foo.*fp)();
}

--------------------------------------------
   .file   "foo.cpp"

 # rs6000/powerpc options: -mcpu=860 -msdata=data -G 8
 # GNU C++ version egcs-2.91.66 19990314 (egcs-1.1.2 release)
(powerpc-linux) compiled by GNU C version egcs-2.91.66 19990314
(egcs-1.1.2 release).
 # options passed:  -mcpu=860 -O4 -Wall -Werror -fverbose-asm
 # options enabled:  -fdefer-pop -fomit-frame-pointer -fcse-follow-jumps

 # -fcse-skip-blocks -fexpensive-optimizations -fthread-jumps
 # -fstrength-reduce -fpeephole -fforce-mem -ffunction-cse
 # -finline-functions -finline -fkeep-static-consts -fcaller-saves
 # -fpcc-struct-return -fgcse -frerun-cse-after-loop -frerun-loop-opt
 # -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec
 # -fexceptions -fsjlj-exceptions -fcommon -fverbose-asm -fgnu-linker
 # -fregmove -foptimize-register-move -fargument-alias -mpowerpc
 # -mnew-mnemonics -msoft-float -mcpu=860 -mcall-sysv -msdata=data

gcc2_compiled.:
    .section    ".text"
    .align 2
    .globl indirect__Fv
    .type    indirect__Fv,@function
indirect__Fv:
    stwu 1,-16(1)
    mflr 0
    stw 0,20(1)
    addis 9,0,fp@ha
    addi 9,9,fp@l
    lha 11,2(9)
    cmpwi 0,11,0
    bc 4,1,.L4
    lha 10,4(9)
    addis 9,0,foo@ha
    addi 9,9,foo@l
    lwzx 0,10,9
    slwi 11,11,2
    add 11,11,0
    lwz 11,-4(11)
    b .L5
.L4:
    lwz 11,4(9)
.L5:
    addis 9,0,fp@ha
    lha 0,fp@l(9)
    addis 3,0,foo@ha
    addi 3,3,foo@l
    add 3,0,3
    mtlr 11
    blrl
    lwz 0,20(1)
    mtlr 0
    la 1,16(1)
    blr
.Lfe1:
    .size    indirect__Fv,.Lfe1-indirect__Fv
    .align 2
    .globl direct__Fv
    .type    direct__Fv,@function
direct__Fv:
    stwu 1,-16(1)
    mflr 0
    stw 0,20(1)
    addis 3,0,foo@ha
    addi 3,3,foo@l
    bl f1__3FOO
    lwz 0,20(1)
    mtlr 0
    la 1,16(1)
    blr
.Lfe2:
    .size    direct__Fv,.Lfe2-direct__Fv
    .globl fp
    .section    ".sdata","aw"
    .align 2
fp:
    .space  8
    .size    fp,8
    .ident  "GCC: (GNU) egcs-2.91.66 19990314 (egcs-1.1.2 release)"
--------------------------------------------

Re: EGCS: pointer to member functions.

[Mike Stump]

> Date: Wed, 16 Jun 1999 08:21:29 +0200
> From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>

> > Thanks, I think you've convinced me it might not be too hard to do
> > this.

> So easily convinced? :-) So what about assignment of
> pointer-to-member?

:-) A couple of things come to mind.  First, types are not first class
objects, and there are no dynamic types in C++.  Or put another way,
for each piece of data, we statically have a notion of type.

> struct FOO
> {    public :
>         virtual void f1();
> };

> extern FOO foo;
> void (FOO::*fp)();

> struct dummy{int i;};
> struct S:dummy,FOO{
>         virtual void f1();
> };

> void (S::*x)();

> int bar()
> {
>   S *s = new S;
>   FOO *foo = s;
>   fp = &FOO::f1;
>   (s->*fp)();      // Thunk expects vtable at offset 0
>   x=fp;

Here we have to build a thunk (thunk(&fp,4)) ontop of the existing
thunk.  Yeah, the hardness you are thinking of is that it has to be
built dynamically.  You then put this thunk into x.

This is almost the previously unsolved linux virtual functions during
ctor/dtor problem.  The difference is that the offset is fixed, but
the function pointer is a variable.  Ok, so we're back to it being
hard.  :-)

>   (s->*x)();       // vtable is at offset 4
> }

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 16, 1999, "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> wrote:

>> Thanks, I think you've convinced me it might not be too hard to do
>> this.

> So easily convinced? :-) So what about assignment of
> pointer-to-member?

>   (s->*fp)();      // Thunk expects vtable at offset 0
>   x=fp;
>   (s->*x)();       // vtable is at offset 4

Interesting, I was thinking about this very problem this morning,
while taking a shower...

I figured out we wouldn't be able to get rid of an offset adjustment
field in the pointer-to-member, but it's still doable, since the
offset is fixed (contravariant casts are ill-formed when crossing
virtual inheritance).  So, the cast operation would just have to
adjust the offset.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 17, 1999, "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> wrote:

>> Opinions?

> Generating pointer-to-member thunks for all member functions seems
> like a big overhead to me.

These would only be generated for the classes involved in a
pointer-to-member-function cast.

> 1. the thunk could receive another implicit parameter, which is the
>    type_info of the static type of the target object. It could then
>    cast this to the right type, and invoke the target method.

I don't think this would be fast enough.  Moreover, adding an argument
opens up a whole new can of worms: think of virtual methods with
variable number of arguments.  If you insert the extra argument in the
beginning of the argument list, you'd have to adjust all the arguments
when dispatching the actual method (which is not trivial on
architectures other than x86), but you can't put it at the end,
because you don't always know where the end is.

> 2. if code size is the problem, we don't have to do the
>    pointer-to-member evaluation inline. It could be a libgcc
>    function.  If course, that would not improve speed, only size -
>    perhaps done with -Os only.
  
Same problem here.  Anyway, I don't think code size is the problem.
The main problem is that the current implementation is slower than it
could be, because it must test for two possible kinds of
pointers-to-methods.  I'm trying to find a way to make it uniform, so
that there's no need for tests and branches in pointer-to-method
handling.  If we also try to save on the size of a pointer-to-method,
we have to use dynamic thunks (which pose the problems I've discussed
in the last message) or static thunks (which must be generated
conservatively, and thus may waste some space).

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 16, 1999, mrs@wrs.com (Mike Stump) wrote:

> Here we have to build a thunk (thunk(&fp,4)) ontop of the existing
> thunk.

But then, it would have to be registered somewhere, to ensure
uniqueness, otherwise pointer-to-members wouldn't compare equal when
they should (or comparison would have to become much more
complicated).

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Martin v. Loewis]

> Why is there so much overhead in calling a function via a pointer as
> apposed to calling it directly ?

Because it's so complicated :-)

> I'm not sure why there are comparison statements (cmpwi).

Two things need to be done:
a) the this-pointer might need to be adjusted, and
b) the call might be a virtual function call

In case of a non-virtual function, part of the member pointer points
to the function. The other part tells that it is a non-virtual
function.

In case of a virtual function, the pointer contains the index into the
virtual method table. The cmpwi is an if-statement determining whether
to do a virtual or a non-virtual call.

Hope this helps,
Martin

Re: EGCS: pointer to member functions.

[Martin v. Loewis]

> Yup, no problem.  You can decide what to do when the pointer is
> created.  If the method is non-virtual, you can just take its address
> directly.  If not, you could take the address of an implicitly-defined
> non-virtual method that works just like a thunk.  This non-virtual
> method could be handled just like template functions, in terms of
> implicit instantiation, so I don't see a problem here.  Is there any
> flaw in my reasoning?

How do you implement contravariant assignment of pointer-to-method?

Regards,
Martin

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 17, 1999, "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> wrote:

>> Opinions?

> Generating pointer-to-member thunks for all member functions seems
> like a big overhead to me.

These would only be generated for the classes involved in a
pointer-to-member-function cast.

> 1. the thunk could receive another implicit parameter, which is the
>    type_info of the static type of the target object. It could then
>    cast this to the right type, and invoke the target method.

I don't think this would be fast enough.  Moreover, adding an argument
opens up a whole new can of worms: think of virtual methods with
variable number of arguments.  If you insert the extra argument in the
beginning of the argument list, you'd have to adjust all the arguments
when dispatching the actual method (which is not trivial on
architectures other than x86), but you can't put it at the end,
because you don't always know where the end is.

> 2. if code size is the problem, we don't have to do the
>    pointer-to-member evaluation inline. It could be a libgcc
>    function.  If course, that would not improve speed, only size -
>    perhaps done with -Os only.
  
Same problem here.  Anyway, I don't think code size is the problem.
The main problem is that the current implementation is slower than it
could be, because it must test for two possible kinds of
pointers-to-methods.  I'm trying to find a way to make it uniform, so
that there's no need for tests and branches in pointer-to-method
handling.  If we also try to save on the size of a pointer-to-method,
we have to use dynamic thunks (which pose the problems I've discussed
in the last message) or static thunks (which must be generated
conservatively, and thus may waste some space).

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Martin v. Loewis]

> Opinions?

Generating pointer-to-member thunks for all member functions seems
like a big overhead to me. In my experience, pointer-to-members are
infrequently used, not justifying the overhead. But then, I thought
that virtual bases are also infrequently used, until I saw the CORBA
Objects-by-value mapping ...

I'll throw some other alternatives into the discussion:

1. the thunk could receive another implicit parameter, which is the
   type_info of the static type of the target object. It could then
   cast this to the right type, and invoke the target method.

2. if code size is the problem, we don't have to do the
   pointer-to-member evaluation inline. It could be a libgcc
   function.  If course, that would not improve speed, only size -
   perhaps done with -Os only.
  
Regards,
Martin

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 16, 1999, mrs@wrs.com (Mike Stump) wrote:

>> From: Alexandre Oliva <oliva@dcc.unicamp.br>
>> Date: 16 Jun 1999 20:13:03 -0300

>> (or comparison would have to become much more complicated).

> Yes.  :-(  Comparisons can run slower, if dispatch is fast.

It seems to me that a pair<pointer_to_thunk,offset> is fast and
general enough, but generating specialized thunks could save us
space.  Do you think it is worth it?

I see a lot of complications in generating offset-thunks dynamically.
If a thunk is just tacked in front of another, a series of casts, such
as base-to-derived and derived-back-to-base would create a sequence of
thunks that just cancel each other.  So, instead of dumbly stacking
offset thunks, we'd have to look into any existing thunk, tell whether
it is an dispatcher thunk or an offset thunk, and combine with an
existing offset thunk.  Maybe the offset thunk could also be combined
with the dispatcher thunk.

In any case, we'd have to dynamically allocate space for these thunks;
unlink in the vtable-thunks case, they can't be stored in the stack
because the casted pointer-to-member may live longer than the current
stack frame.


A design that comes to my mind is to construct pointer-to-member
mapping tables that, given a dispatcher thunk of a base class (say,
its address, or an index based on the order of declaration of the
methods in the base class), return the dispatcher thunk for the
derived class, and another that performs the reverse mapping.  The
disadvantage of this scheme is that dispatcher thunks would have to be
instantiated for each member of the classes involved in the type-cast.
We could generate weak definitions for the base thunks, to save some
space.  But if the point of using offset thunks is to save space, I'm
not really sure it does, since we'd have to add all this garbage any
time a pointer-to-member typecast is found.  But then, it's all static
data, and, if you create a lot of pointers-to-methods, it may pay
off...

Opinions?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Joe Buck]

> > Here we have to build a thunk (thunk(&fp,4)) ontop of the existing
> > thunk.
> 
> But then, it would have to be registered somewhere, to ensure
> uniqueness, otherwise pointer-to-members wouldn't compare equal when
> they should (or comparison would have to become much more
> complicated).

Comparing pointers to member functions for equality (for values other than
null) is a far rarer operation than assignment (I've never seen anyone do
it).  It would be appropriate to make assignment faster in exchange for
making comparison slower.

But the new design would have to support comparison, it seems.  Yuk.

Re: EGCS: pointer to member functions.

[Mike Stump]

> From: Alexandre Oliva <oliva@dcc.unicamp.br>
> Date: 16 Jun 1999 20:13:03 -0300

> (or comparison would have to become much more complicated).

Yes.  :-(  Comparisons can run slower, if dispatch is fast.
Comparisons are evil and bad style.

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 16, 1999, mrs@wrs.com (Mike Stump) wrote:

> Here we have to build a thunk (thunk(&fp,4)) ontop of the existing
> thunk.

But then, it would have to be registered somewhere, to ensure
uniqueness, otherwise pointer-to-members wouldn't compare equal when
they should (or comparison would have to become much more
complicated).

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 16, 1999, "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> wrote:

>> Thanks, I think you've convinced me it might not be too hard to do
>> this.

> So easily convinced? :-) So what about assignment of
> pointer-to-member?

>   (s->*fp)();      // Thunk expects vtable at offset 0
>   x=fp;
>   (s->*x)();       // vtable is at offset 4

Interesting, I was thinking about this very problem this morning,
while taking a shower...

I figured out we wouldn't be able to get rid of an offset adjustment
field in the pointer-to-member, but it's still doable, since the
offset is fixed (contravariant casts are ill-formed when crossing
virtual inheritance).  So, the cast operation would just have to
adjust the offset.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Mike Stump]

> Date: Wed, 16 Jun 1999 08:21:29 +0200
> From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>

> > Thanks, I think you've convinced me it might not be too hard to do
> > this.

> So easily convinced? :-) So what about assignment of
> pointer-to-member?

:-) A couple of things come to mind.  First, types are not first class
objects, and there are no dynamic types in C++.  Or put another way,
for each piece of data, we statically have a notion of type.

> struct FOO
> {    public :
>         virtual void f1();
> };

> extern FOO foo;
> void (FOO::*fp)();

> struct dummy{int i;};
> struct S:dummy,FOO{
>         virtual void f1();
> };

> void (S::*x)();

> int bar()
> {
>   S *s = new S;
>   FOO *foo = s;
>   fp = &FOO::f1;
>   (s->*fp)();      // Thunk expects vtable at offset 0
>   x=fp;

Here we have to build a thunk (thunk(&fp,4)) ontop of the existing
thunk.  Yeah, the hardness you are thinking of is that it has to be
built dynamically.  You then put this thunk into x.

This is almost the previously unsolved linux virtual functions during
ctor/dtor problem.  The difference is that the offset is fixed, but
the function pointer is a variable.  Ok, so we're back to it being
hard.  :-)

>   (s->*x)();       // vtable is at offset 4
> }

Re: EGCS: pointer to member functions.

[Martin v. Loewis]

> Thanks, I think you've convinced me it might not be too hard to do
> this.

So easily convinced? :-) So what about assignment of
pointer-to-member?

struct FOO
{    public :
        virtual void f1();
};

extern FOO foo;
void (FOO::*fp)();

struct dummy{int i;};
struct S:dummy,FOO{
        virtual void f1();
};

void (S::*x)();

int bar()
{
  S *s = new S;
  FOO *foo = s;
  fp = &FOO::f1;
  (s->*fp)();      // Thunk expects vtable at offset 0
  x=fp;
  (s->*x)();       // vtable is at offset 4
}

Regards,
Martin

Re: EGCS: pointer to member functions.

[Mike Stump]

> From: Alexandre Oliva <oliva@dcc.unicamp.br>
> Date: 15 Jun 1999 17:08:52 -0300

> you could take the address of an implicitly-defined non-virtual
> method that works just like a thunk.

Thanks, I think you've convinced me it might not be too hard to do
this.  In fact this might be a good `fix' to the existing thunk
vtables code.

Wanna edit it into the projects page?

Re: EGCS: pointer to member functions.

[Martin v. Loewis]

> Yup, no problem.  You can decide what to do when the pointer is
> created.  If the method is non-virtual, you can just take its address
> directly.  If not, you could take the address of an implicitly-defined
> non-virtual method that works just like a thunk.  This non-virtual
> method could be handled just like template functions, in terms of
> implicit instantiation, so I don't see a problem here.  Is there any
> flaw in my reasoning?

How do you implement contravariant assignment of pointer-to-method?

Regards,
Martin

Re: EGCS: pointer to member functions.

[Martin v. Loewis]

> Why is there so much overhead in calling a function via a pointer as
> apposed to calling it directly ?

Because it's so complicated :-)

> I'm not sure why there are comparison statements (cmpwi).

Two things need to be done:
a) the this-pointer might need to be adjusted, and
b) the call might be a virtual function call

In case of a non-virtual function, part of the member pointer points
to the function. The other part tells that it is a non-virtual
function.

In case of a virtual function, the pointer contains the index into the
virtual method table. The cmpwi is an if-statement determining whether
to do a virtual or a non-virtual call.

Hope this helps,
Martin

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 15, 1999, mrs@wrs.com (Mike Stump) wrote:

>> From: Alexandre Oliva <oliva@dcc.unicamp.br>
>> Date: 15 Jun 1999 03:54:56 -0300

>> On Jun 15, 1999, Brendan Simon <brendan@dgs.monash.edu.au> wrote:

>> > Why is there so much overhead in calling a function via a pointer as
>> > apposed to calling it directly?

>> Pointer-to-methods don't know whether they point to virtual methods or
>> not, so the caller must have code for both cases.  Methinks this could
>> be improved by generating thunks that perform dynamic binding in the
>> case of invoking virtual methods, but maybe I'm missing something.

> Try it, lay it out, read up on C++ and what is required of the
> generated code.  :-) I have, I think.  :-) Hint, there is no separate
> type for pointer to virtual method and pointer to non-virtual member.

Yup, no problem.  You can decide what to do when the pointer is
created.  If the method is non-virtual, you can just take its address
directly.  If not, you could take the address of an implicitly-defined
non-virtual method that works just like a thunk.  This non-virtual
method could be handled just like template functions, in terms of
implicit instantiation, so I don't see a problem here.  Is there any
flaw in my reasoning?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: EGCS: pointer to member functions.

[Mike Stump]

> From: Alexandre Oliva <oliva@dcc.unicamp.br>
> Date: 15 Jun 1999 03:54:56 -0300

> On Jun 15, 1999, Brendan Simon <brendan@dgs.monash.edu.au> wrote:

> > Why is there so much overhead in calling a function via a pointer as
> > apposed to calling it directly?

> Pointer-to-methods don't know whether they point to virtual methods or
> not, so the caller must have code for both cases.  Methinks this could
> be improved by generating thunks that perform dynamic binding in the
> case of invoking virtual methods, but maybe I'm missing something.

Try it, lay it out, read up on C++ and what is required of the
generated code.  :-) I have, I think.  :-) Hint, there is no separate
type for pointer to virtual method and pointer to non-virtual member.
Now, complete program analysis and code complete generation at link
time trivially solves this problem.  This means that one could put the
info into the repo file, and just call a recompile pass for any files
that then don't meet the flexibility requirements.

But, I whimped out and did it the easy way.

Re: EGCS: pointer to member functions.

[Mike Stump]

> Date: Tue, 15 Jun 1999 06:28:16 +0000
> From: Brendan Simon <brendan@dgs.monash.edu.au>
> To: egcs mailing list <egcs@egcs.cygnus.com>

> egcs-1.1.2 powerpc-linux-crosscompiler, RedHat 5.2 Linux.

> I decided that the FSM actions would be member funtions of an FSM
> class.  I had a look at the generated assembly and am quite
> astonished at the code that is generated.  Why is there so much
> overhead in calling a function via a pointer as apposed to calling
> it directly ?

Because 20 years from now, someone will reuse your code, and use
multiple inheritance and virtual member functions and other such neat
features and they will expect the code to just work.

A member function is not a C function, it is a proper superset.  If
you want just a simple function, use a static member function, and
pass it the this pointer as the first argument.

Welcome to C++.

Re: EGCS: pointer to member functions.

[Alexandre Oliva]

On Jun 15, 1999, Brendan Simon <brendan@dgs.monash.edu.au> wrote:

> Why is there so much overhead in calling a function via a pointer as
> apposed to calling it directly?

Pointer-to-methods don't know whether they point to virtual methods or
not, so the caller must have code for both cases.  Methinks this could
be improved by generating thunks that perform dynamic binding in the
case of invoking virtual methods, but maybe I'm missing something.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

EGCS: pointer to member functions.

[Brendan Simon]

egcs-1.1.2 powerpc-linux-crosscompiler, RedHat 5.2 Linux.

I am implementing a finate state machine using a 2 dimensional array.  I
decided that the FSM actions would be member funtions of an FSM class.
I had a look at the generated assembly and am quite astonished at the
code that is generated.  Why is there so much overhead in calling a
function via a pointer as apposed to calling it directly ?  I'm not sure
why there are comparison statements (cmpwi).  The .cpp and .s files
follow.

--------------------------------------------

class FOO
{    public :
        void    f1();
};

extern FOO foo;
void (FOO::*fp)();  // pointer to FOO member function.

void direct()
{
    foo.f1();
}

void indirect()
{
    (foo.*fp)();
}

--------------------------------------------
   .file   "foo.cpp"

 # rs6000/powerpc options: -mcpu=860 -msdata=data -G 8
 # GNU C++ version egcs-2.91.66 19990314 (egcs-1.1.2 release)
(powerpc-linux) compiled by GNU C version egcs-2.91.66 19990314
(egcs-1.1.2 release).
 # options passed:  -mcpu=860 -O4 -Wall -Werror -fverbose-asm
 # options enabled:  -fdefer-pop -fomit-frame-pointer -fcse-follow-jumps

 # -fcse-skip-blocks -fexpensive-optimizations -fthread-jumps
 # -fstrength-reduce -fpeephole -fforce-mem -ffunction-cse
 # -finline-functions -finline -fkeep-static-consts -fcaller-saves
 # -fpcc-struct-return -fgcse -frerun-cse-after-loop -frerun-loop-opt
 # -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec
 # -fexceptions -fsjlj-exceptions -fcommon -fverbose-asm -fgnu-linker
 # -fregmove -foptimize-register-move -fargument-alias -mpowerpc
 # -mnew-mnemonics -msoft-float -mcpu=860 -mcall-sysv -msdata=data

gcc2_compiled.:
    .section    ".text"
    .align 2
    .globl indirect__Fv
    .type    indirect__Fv,@function
indirect__Fv:
    stwu 1,-16(1)
    mflr 0
    stw 0,20(1)
    addis 9,0,fp@ha
    addi 9,9,fp@l
    lha 11,2(9)
    cmpwi 0,11,0
    bc 4,1,.L4
    lha 10,4(9)
    addis 9,0,foo@ha
    addi 9,9,foo@l
    lwzx 0,10,9
    slwi 11,11,2
    add 11,11,0
    lwz 11,-4(11)
    b .L5
.L4:
    lwz 11,4(9)
.L5:
    addis 9,0,fp@ha
    lha 0,fp@l(9)
    addis 3,0,foo@ha
    addi 3,3,foo@l
    add 3,0,3
    mtlr 11
    blrl
    lwz 0,20(1)
    mtlr 0
    la 1,16(1)
    blr
.Lfe1:
    .size    indirect__Fv,.Lfe1-indirect__Fv
    .align 2
    .globl direct__Fv
    .type    direct__Fv,@function
direct__Fv:
    stwu 1,-16(1)
    mflr 0
    stw 0,20(1)
    addis 3,0,foo@ha
    addi 3,3,foo@l
    bl f1__3FOO
    lwz 0,20(1)
    mtlr 0
    la 1,16(1)
    blr
.Lfe2:
    .size    direct__Fv,.Lfe2-direct__Fv
    .globl fp
    .section    ".sdata","aw"
    .align 2
fp:
    .space  8
    .size    fp,8
    .ident  "GCC: (GNU) egcs-2.91.66 19990314 (egcs-1.1.2 release)"
--------------------------------------------