[llvm-dev] Call via Vtable

[Madhur Amilkanthwar via llvm-dev]

FWIW, If I add the main() to call fred() and then I do see
<https://godbolt.org/z/WPvbed8f6>the constant being inlined as expected at
O1 and above.
What is the optimization level you're trying at? I think code generated at
O0 level for both compilers may vary significantly due to different pass
configurations.



On Mon, Jul 12, 2021 at 11:30 AM 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?
>
>
>
> -
>
> Santanu Das
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


-- 
*Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this
mail are of my own and my employer has no take in it. *
Thank You.
Madhur D. Amilkanthwar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210712/aa7166a0/attachment.html>