On Tue, Apr 19, 2011 at 2:15 AM, Jan Hubicka <hubi...@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 >
