This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: EGCS: pointer to member functions.
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