[cfe-dev] Virtual function call optimization(memoization) questions

[Ninu-Ciprian Marginean via cfe-dev]

" 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>
wrote:

> 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:
>> https://godbolt.org/z/WFp2rm
>>
>> 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.
> https://godbolt.org/z/arzMYD
> Even marking the stack objects as `const` didn't help, which surprises me
> in this case:
> https://godbolt.org/z/CpMMkd
>
> –Arthur
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200617/7c3feccb/attachment-0001.html>