http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507
Jan Hubicka <hubicka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2014-01-16
CC| |hubicka at gcc dot gnu.org,
| |rguenther at suse dot de
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #7 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, GIMPLE representation is pre-inlining as follows:
void arg_tuple_test(const std::pair<A, A>&) (const struct pair & t)
{
const struct type & _2;
const struct type & _3;
int (*__vtbl_ptr_type) () * _5;
int (*__vtbl_ptr_type) () _6;
<bb 2>:
_2 = std::get<0ul, A, A> (t_1(D));
_3 = _2;
_5 = _3->_vptr.A;
_6 = *_5;
OBJ_TYPE_REF(_6;(const struct A)_3->0) (_3);
return;
}
Here I do not think we can devirtualize, because std::get can return a derived
type in general.
After inlining we get:
void arg_tuple_test(const std::pair<A, A>&) (const struct pair & t)
{
int (*__vtbl_ptr_type) () * _3;
int (*__vtbl_ptr_type) () _4;
const struct A & _6;
<bb 2>:
_6 = &t_1(D)->first;
_3 = MEM[(const struct type *)t_1(D)]._vptr.A;
_4 = *_3;
OBJ_TYPE_REF(_4;(const struct A)_6->0) (_6); [tail call]
return;
}
Here we look all the way to figuring out that the object comes as parameter of
arg_tuple_test and give up on this point.
I think GIMPLE typing rules does not really allow us to take the type from
COMPONENT_REF in statement defining _6, so it seems we completely lose track of
the type info here. (and it indeed looks like a common case)
Richard?
