[cfe-dev] Virtual function call optimization(memoization) questions
Ninu-Ciprian Marginean via cfe-dev
cfe-dev at lists.llvm.org
Tue Jun 16 16:08:57 PDT 2020
" but the compiler cannot make that assumption because the C++ Standard
technically permits a virtual method to destroy and re-create `b` with a
completely different dynamic type." - thanks, I wasn't aware of this. I'll
look into the smart pointer lifetime optimizations thread soon.
On Tue, Jun 16, 2020 at 6:27 PM Arthur O'Dwyer <arthur.j.odwyer at gmail.com>
> On Tue, Jun 16, 2020 at 2:31 AM Ninu-Ciprian Marginean via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>> I have a virtual function call in a loop. All the time, the same method
>> is called:
>> The loop is in method work; the virtual call is to method id.
>> We can see that method work gets inlined, but inside the loop, there are
>> always two pointer dereferences:
>> mov rax, qword ptr [r14]
>> call qword ptr [rax]
>> Since the object referred to by b, never changes to a different object,
>> this could(at least in this case), be cached.
> I believe that this is a similar problem to what was recently discussed in
> the thread titled "[cfe-dev] Smart Pointer Lifetime Optimizations". In
> this case (as in that case), the human programmer knows that the call to
> `b->do_id()` does not actually change the value of b's vptr; but the
> compiler cannot make that assumption because the C++ Standard technically
> permits a virtual method to destroy and re-create `b` with a completely
> different dynamic type.
> As in the smart-pointer case, Clang provides a "noescape" attribute that
> addresses half of the problem, but doesn't provide any "really_const"
> attribute that allows the human programmer to say "Look, I promise that
> this function call *really does not change* its argument!" (I think
> LLVM's `readonly` attribute would help, but Clang does not expose that
> attribute to the C++ programmer.)
> I tried slapping all the attributes I could think of onto this member
> function — noescape, const, pure — and none of them helped.
> Even marking the stack objects as `const` didn't help, which surprises me
> in this case:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev