[cfe-dev] Could key functions be used to reason about availability of inline method definitions?

[David Blaikie via cfe-dev]

Nothing immediately jumps out at me as making this invalid... (but I have a
nagging feeling that there probably is an issue and I'm likely missing it -
I imagine Richard Smith (CC'd), John McCall, etc, would be more likely to
spot the nuances here)

On Mon, May 28, 2018 at 7:47 AM Hans Wennborg via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> I was poking around some object files and noticed function definitions
> that seemed unnecessary. They were for inline functions not actually
> used in the file except by reference from a vtable.
>
> For example:
>
>   struct Rectangle {
>     virtual int colour() { return 1; }
>     virtual void draw();
>   };
>
>   struct Square : public Rectangle {
>     virtual void draw() override;
>   };
>
>   void Square::draw() {}
>
> Both Clang and GCC will emit a definition of Rectangle::colour() here
> because it's referenced by Square's vtable which we must define, and
> it's an inline function so we don't know if it's defined anywhere
> else.
>
> But, don't we actually know it's defined elsewhere? Since Rectangle
> has a key function, its vtable will be defined elsewhere. That vtable
> will reference Rectangle::colour(), so that too must have a definition
> elsewhere. Could we use this reasoning to omit the definition of
> colour() in the current TU, or at least mark it available_externally?
>
> I'm thinking exploiting this could allow the compiler to emit a bit
> less code. Or is there something I'm missing?
>
> Cheers,
> Hans
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180528/0d3f42d5/attachment.html>