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. Ian
