http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507
--- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> --- I agree we want to do as much as possible in FE. ODR decisions are basically done in frontend now - we basically use mangling of virtual tables given to us by C++ FE. Eventually we will want to get ODR information on all types, not only polymorphic ones. Then I plan to go with Jason's suggested way of calling decl_assembler name on types to get mangling from C++ FE rather than my initial attempt to actually compare types for equivalence by their high level names that hits interesting issues with templates. It is left in code mostly as backup if the other solution blows up our memory footprint. I do not think we can do type inheritance analysis + devirtualization purely by frotnend, since it is naturally an inter-procuedural problem that needs to be handled by LTO. We already have sane way to represent the type inheritance tree by binfos. What we need to work on is a sane and safe way representing the relevant type information that is given to you by C++ standard but thrown away on way to GIMPLE so the propagation can work. I was thinking of type assert expressions that can be inserted by FE on places where dynamic type is known for non-trivial reasons. Those can be used as starting points for the propagation of type information and removed after IPA. This would allow us to preserve information while inlining and also make it easier to deal with dynamic type changes. For simple operations, like in this testcase, this approach may be however impractical producing too many new gimple statements. I am slowly getting to stage where current devirt infrastructure seems to work as expected and seems to use most of information already there in gimple that seems to be safe to assume. My plan was to basically wait for this release cycle, see how many bugs shows up so I am sure I do not miss something obvious (well, like the virtual inheritance fun). I think only parts we miss now is to - move ipa-cp to new infrastructure - move dynamic type change code to ipa-devirt and make it work with contextes - understand ctors/dtors calls, since we already ave flag marking them specially. I also collected testcases we need to handle. I will try to sit down and prepare some proposal about what we need to preserve in gimple. I think we also want central place (probably in ipa-devirt toplevel comment) documenting all the information we take into account and assumptions we make. So far they are mostly trivial (i.e. static vars/automatic vars/values passed by invisible references are known to have their type and not derived type) except for Martin's dynamic changing code.
