<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On May 28, 2018, at 2:27 PM, Richard Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class="gmail_quote" dir="auto"><div dir="ltr" class="">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.</div></div></div></div></blockquote><div><br class=""></div>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.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="gmail_quote" dir="auto"><div dir="ltr" class="">There might also be symbol visibility issues (eg with -fvisibility-inlines-hidden).</div></div></div></div></blockquote><div><br class=""></div>Yeah, this is probably the biggest practical problem that would come up.</div><div><br class=""></div><div>John.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="gmail_quote" dir="auto"><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">On Mon, 28 May 2018, 10:48 David Blaikie via cfe-dev, <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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)<div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, May 28, 2018 at 7:47 AM Hans Wennborg via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was poking around some object files and noticed function definitions<br class="">
that seemed unnecessary. They were for inline functions not actually<br class="">
used in the file except by reference from a vtable.<br class="">
<br class="">
For example:<br class="">
<br class="">
struct Rectangle {<br class="">
virtual int colour() { return 1; }<br class="">
virtual void draw();<br class="">
};<br class="">
<br class="">
struct Square : public Rectangle {<br class="">
virtual void draw() override;<br class="">
};<br class="">
<br class="">
void Square::draw() {}<br class="">
<br class="">
Both Clang and GCC will emit a definition of Rectangle::colour() here<br class="">
because it's referenced by Square's vtable which we must define, and<br class="">
it's an inline function so we don't know if it's defined anywhere<br class="">
else.<br class="">
<br class="">
But, don't we actually know it's defined elsewhere? Since Rectangle<br class="">
has a key function, its vtable will be defined elsewhere. That vtable<br class="">
will reference Rectangle::colour(), so that too must have a definition<br class="">
elsewhere. Could we use this reasoning to omit the definition of<br class="">
colour() in the current TU, or at least mark it available_externally?<br class="">
<br class="">
I'm thinking exploiting this could allow the compiler to emit a bit<br class="">
less code. Or is there something I'm missing?<br class="">
<br class="">
Cheers,<br class="">
Hans<br class="">
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div></div></div>
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div></div>
_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></blockquote></div><br class=""></body></html>