This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix incorrect devirtualization (PR middle-end/48661)
On Tue, Apr 19, 2011 at 2:15 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> > Hi!
>> >
>> > If TREE_BINFO has BV_VCALL_INDEX set, this needs to be dynamically
>> > adjusted, but none of the callers are prepared to handle that.
>> > Thus, this patch makes devirtualization give up in those cases.
>> >
>> > Bootstrapped/regtested on x86_64-linux and i686-linux, trunk and 4.6.
>> > On the trunk the testcase ICEs before and after the patch in some new callgraph
>> > checking (added today or so, Honza?), on the branch it works just fine.
>>
>> The ICE for me is:
>> jakub.C:77:1: error: a call to thunk improperly represented in the call graph:
>> # VUSE <.MEM_11>
>> D.2319_3 = D::_ZTv0_n24_NK1D1mEv (&q.D.2159);
>>
>> void test()/26(14) @0x7ffff77066f0 (asm: _Z4testv) availability:available analyzed needed reachable body externally_visible finalized
>> ? called by: int main()/28 (1.00 per call) (can throw external)
>> ? calls: void bar(int)/1 (1.00 per call) void bar(int)/1 (1.00 per call) virtual int D::m() const/15 (1.00 per call) D::D(const A&)/14 (1.00 per call)
>> ? References:
>> ? Refering this function:
>> ? has 3 outgoing edges for indirect calls.
>>
>> this is not my snaity check, but Martins and I think it means that somehow your
>> change is ineffective on mainline and we still devirtualize.
>> Martin, I declare this problem yours.
>
> Actually what happens here is that CCP devirtualize by propagating the
> constructors and due to Richard's new code to drop OBJ_TYPE_REF we finally get
> a direct call. ?This is all good and desirable.
>
> I think good solution would be to fold further and inline the thunk adjustment,
> just like the type based devirtualization does. ?Even once I get far enough
> with my cgraph cleanuping project to make cgraph represent thunks nicely, we
> would win if in these cases ccp and other passes simply inlined the this adjustment,
> like we do with type based devirtualization already.
> Martin, I guess it is matter of looking up the thunk info by associated cgraph node
> alias and extending fold_stmts of passes that now drop the OBJ_TYPE_REF wrappers?
Huh. No, I don't think we want to do any "inlining" as part of
folding. At least not if it
is a correctness issue (is it?). Why does the inliner not simply
inline the thunk function
body?
Richard.
> Honza
>