On Fri, Mar 9, 2018 at 2:08 PM, Nathan Sidwell <nat...@acm.org> wrote: > On 03/09/2018 06:51 AM, Richard Biener wrote: >> >> On Fri, Mar 9, 2018 at 11:32 AM, Richard Biener >> <richard.guent...@gmail.com> wrote: > > >> callgrind shows that propagate_binfo_offsets recursing >> to self very many times is likely the issue. Your templates >> build a very deep inheritance chain and it seems that >> the binfo offset propagation ends up being exponential here. >> >> I would have expected that any bases have already correct >> offsets so we don't need the recursion to bases of bases? >> >> Ah, so in this case we have offset of 1 because sizeof is >> always nonzero. So the issue might just be that >> BINFO_OFFSET is not relative to the parent? > > > Correct, it's relative to the complete object. > >> doens't improve things. We call this functions millions of times >> creating millions of INTEGER_CSTs. Can BINFO_OFFSET be >> non-constant? > > > No. (if it's a vbase, it shows the offset in the complete object, IIRC, and > there's other data to let code generation know some vtable inspection is > needed when the dynamic type is unknown).
So there's no multiple inheritance of classes with VLA members then I guess. Or rather there's no such thing as VLA members ;) If it's always constant I suggest to make it a non-tree ... I suspect while not addressing the complexity it would improve compile-time a lot... Oh, and in the testcase there's no virtual methods so nobody should look at BINFO_OFFSET anyway? Richard. > nathan > > -- > Nathan Sidwell
