[Bug tree-optimization/46507] std::get and devirtualization on non-automatic variables

["hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.