<div dir="ltr"><div dir="ltr">On Fri, 24 Jul 2020 at 02:42, David Chisnall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 24/07/2020 01:46, David Blaikie via llvm-dev wrote:<br>
> I believe C++ requires that all functions have a distinct address (ie:<br>
> &f1 != &f2) and LLVM optimizes code on this basis (assert(f1 == f2)<br>
> gets optimized into an unconditional assertion failure)<br>
> <br>
> But these zero length functions can end up with identical addresses.<br>
> <br>
> I'm unaware of anything in the C++ spec (or the LLVM langref) that<br>
> would indicate that would allow distinct functions to have identical<br>
> addresses - so should we do something about this in the LLVM backend?<br>
> add a little padding? a nop instruction? (if we're adding an<br>
> instruction anyway, perhaps we might as well make it an int3?)<br>
<br>
This is also a problem with identical function merging in the linker, <br>
which link.exe does quite aggressively.  The special case of zero-length <br>
functions seems less common than the more general case of merging, in <br>
both cases you will end up with a single implementation in the binary <br>
that has two symbols for the same address.  For example, consider the <br>
following trivial program:<br>
<br>
#include <stdio.h><br>
<br>
int a()<br>
{<br>
         return 42;<br>
}<br>
<br>
int b()<br>
{<br>
         return 42;<br>
}<br>
<br>
int main()<br>
{<br>
         printf("a == b? %d\n", a == b);<br>
         return 0;<br>
}<br>
<br>
Compiled with cl.exe /Gy, this prints:<br>
<br>
a == b? 1<br>
<br>
Given that functions are immutable, it's a somewhat odd decision at the <br>
abstract machine level to assume that they have identity that is <br>
distinct from their value (though it can simplify debugging - back <br>
traces in Windows executables are sometimes quite confusing when you see <br>
a call into a function that is structurally correct but nominally <br>
incorrect).<br>
<br>
Given that link.exe can happily violate this guarantee in the general <br>
case, I'm not too concerned that LLVM can violate it in the special <br>
case.  From the perspective of a programmer, I'm not sure what kind of <br>
logic would be broken by function equality returning true when two <br>
functions with different names but identical behaviour are invoked.  I'm <br>
curious if you have any examples.<br></blockquote><div><br></div><div>This is a well-known conformance-violating bug in link.exe; LLVM should not be making things worse by introducing a similar bug itself. Smarter linkers (for example, I think both lld and gold) will do identical function combining only if all but one of the function symbols is only used as the target of calls (and not to actually observe the address). And yes, this non-conforming behavior (rarely) breaks things in practice. See this research paper: <a href="https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36912.pdf">https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36912.pdf</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
David<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>