Hi Richard,
What makes it different when we add main()? Isn't the complexity be same?
On Tue, Jul 13, 2021, 10:21 AM Richard Smith via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Sun, 11 Jul 2021 at 23:00, Santanu Das via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hello community members,
>>
>>
>>
>> I was experimenting to see whether LLVM is able to devirtualize calls
via
>> vtable. I have this particular example:
>>
>>
>>
>> =======>>
>> class Foo {
>>
>> public:
>>
>> virtual int foo() const = 0;
>>
>> int baz() const { return foo(); }
>>
>> };
>>
>>
>>
>> class Bar : public Foo {
>>
>> public:
>>
>> int foo() const override final { return 0xdeadbeef; }
>>
>> };
>>
>>
>>
>> int fred(Bar &x) {
>>
>> return x.baz();
>>
>> }
>>
>> =======>>
>>
>>
>> As we can see, there is a call to Bar::foo(), via Foo::baz(), which
>> returns a constant.
>>
>> The Bar::foo() function has final specifier, hence this implementation
>> cannot be overridden by any child class. In this case, the compiler
should
>> be able to call Bar::foo() directly instead of calling via vtable, and
then
>> should be able to inline the const value.
>>
>>
>>
>> When I compile with LLVM main branch, I see this piece of code being
>> generated below. It makes a call to the function via vtable entry.
>>
>>
>>
>> _Z4fredR3Bar:
>>
>> movq (%rdi), %rax
>>
>> jmpq *(%rax)
>>
>>
>>
>>
>>
>> When I compile with GCC, I see that it is able to correctly identify
that
>> it should call Bar::foo() directly and successfully inlines the const
value.
>>
>>
>>
>> _Z4fredR3Bar:
>>
>> movq (%rdi), %rax
>>
>> movq (%rax), %rax
>>
>> cmpq $_ZNK3Bar3fooEv, %rax
>>
>> jne .L5
>>
>> movl $-559038737, %eax
>>
>> ret
>>
>>
>>
>>
>>
>> Should LLVM be optimizing this call, or am I missing something?
>>
>
> LLVM knows nothing about whether functions are "final"; most
facts about
> the C++ type system are not representable in LLVM IR. The optimizations
> based on "final" are all done by Clang as part of lowering to
LLVM IR.
> Clang would happily devirtualize a call to x.foo(), because it can locally
> see that would be a virtual call to a final function, so must call
> Bar::foo(), but in this example Clang can't do anything because it only
> reasons about the program before optimization, and LLVM can't do
anything
> because the "final" information is not represented in LLVM IR.
>
> The information we'd need to propagate into the optimizer here would be
> moderately complex: we don't know what x's vptr is at the point of
the call
> to baz() (it could be that of Bar or of a class derived from Bar), but we
> do know what a certain slot in that vptr contains (or at least, we know a
> function that is equivalent to that slot's value -- I don't think
there's a
> guarantee it's actually the same value). It'd probably be feasible
to add
> support to LLVM to model that kind of thing, but it would probably require
> a fair bit of work.
>
>
>> -
>>
>> Santanu Das
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210713/53333d39/attachment.html>