> >
>
> I think it would be better, yes. IIRC, We want to re-organize
> indirect_info anyway (I vaguely remember we want to split the
> overloaded offset field into two but forgot the exact reason why but I
> have it written somewhere), I suppose we'll be turning it into a union
> (or class hierarchy?) and this would make it slightly awkward. If we
> ever support the pointer-by-reference scenario, quite a few more
> places will need to be adjusted anyway.
OK, I will remove the check. I wanted to split polymorphic call context
and its propagation from aggregate analysis. For example
struct A
{
struct B b;
struct C c;
}
when you call method of A.c.foo() its context is not
{outer_type=a,offset=offsetof(c)}, since A is not polymorphic type at all. We
should instead use {outer_type=c,offset=0,not_derived_type}. In
ipa-devirt there is function get_class_context that gets you from first to
second.
So as briefly discussed last july, I think ipa-prop can simply do two
propagations in parallel where the type one is done via functionality that
willbe exported from ipa-devirt, since the logic should be shared with
a local devirt pass.
There are also cases where the parameter is KNOWN_TYPE but also PASS_THROUGH at
the same type (as tings passed by invisible refernece, or when the function is
constructor and it initialized dynamic type of THIS pointer).
Those are cases where current code is losing information because one is not
supperset of the other. We want to use KNOWN_TYPE information for
devirtualization,
but we do not want to forget about PASS_THROUGH for normal constant propagation
in
case constructor is only called on &decl.
Honza
>
> Thanks,
>
> Martin
