Re: [RFC] Migrate pointers to members to the middle end

["Daniel Berlin" <dberlin at dberlin dot org>]

On 08 Aug 2007 17:36:43 -0700, Ian Lance Taylor <iant@google.com> wrote:
> Michael Matz <matz@suse.de> writes:
>
> > If you were to implement something like virtual functions into the middle
> > end, it should be expressed in a fairly low level way IMHO.  E.g. a
> > virtual table simply being a vector of pointers to function decls (which
> > we can express already just fine).  That way they could also be written
> > out for LTO and read back in, and the question what function decl is
> > connected to what slot can also be answered trivially.  Then definite
> > class type merely has the characteristic that they can point to such a
> > function table, whereas indefinite class types (i.e. those whose runtime
> > type can be any derived one) can not.  E.g. I wouldn't try to model the
> > inheritance relationship.
>
> There is some advantage to knowing class heirarchy relationships in
> LTO.  Some C++ programs implement different virtual subclasses in
> different files.  LTO can put those together.  When the compiler can
> then determine that a variable definitely has a particular subclass,
> it can devirtualize the virtual calls, turning an indirect function
> call into a direct function calls, also exposing inlining
> opportunities.
>
> I don't know how important an optimization this is, but it seems like
> a real one, and one which is only available if the LTO middle-end
> knows something about class relationships.

I believe we do want to have this info in the middle end, but i don't
necessarily believe what Ollie's current approach is the best one.

It looks like all the code is still C++ specific, and it's semantics
are only defined by how they get generated in cp/*

I'd rather see us go the route of deciding what the semantics *should
be*, which of these tree codes are *actually necessary*, then make
cp/* gimplify it to what we've got.  The semantics should also be
completely documented independently of the C++ FE (even if we were
decide to give the middle end codes the exact same semantics as C++)

For example, I see no reason for PTRMEM_PLUS_EXPR.

To put it concretely, i think the proposal has gone backwards, and
worked from "we have an implementation of something in the C++ FE,
let's move it to the middle end" instead of "we have a design for
something we want to do in the middle end, let's make the C++
FE/gimplifier do it".

It's not at all clear to me from the current proposal where/when/how
these tree codes occur in the normal GIMPLE datastream, how I would
handle them in points-to analysis, etc.

Note that to directly adress your point, the middle end *already does*
have a notion of class relationships.  The BINFO_* (base class
information) is already common to the middle-end.  This is how the
ipa-cha stuff that was submitted a while ago knows how to find base
classes.

Besides type-based devirt, you will also get a lot out of points-to
based devirt, because it can do without the whole program, whereas
type-based devirt cannot.

--Dan