On 08 Aug 2007 17:36:43 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > Michael Matz <[EMAIL PROTECTED]> 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
