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

John McCall via cfe-dev cfe-dev at lists.llvm.org
Tue May 29 01:04:57 PDT 2018


> On May 28, 2018, at 2:27 PM, Richard Smith via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> Theoretically, there is no requirement that a symbol for Rectangle::colour be provided by the object file with the key function. In practice I'd expect the symbol would probably be provided anyway, but I think this would formally be a new ABI requirement.

Right.  It's not an unreasonable requirement — at least if it comes with a guarantee that other translation units *won't* emit those functions, so that the key-function translation unit can emit them as strong definitions — but it's not one made by the ABI today.

> There might also be symbol visibility issues (eg with -fvisibility-inlines-hidden).

Yeah, this is probably the biggest practical problem that would come up.

John.

> 
> On Mon, 28 May 2018, 10:48 David Blaikie via cfe-dev, <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> 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 <mailto: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 <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> _______________________________________________
> 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/20180529/1b639838/attachment.html>


More information about the cfe-dev mailing list