On 24/07/2020 01:46, David Blaikie via llvm-dev wrote: > I believe C++ requires that all functions have a distinct address (ie: > &f1 != &f2) and LLVM optimizes code on this basis (assert(f1 == f2) > gets optimized into an unconditional assertion failure) > > But these zero length functions can end up with identical addresses. > > I'm unaware of anything in the C++ spec (or the LLVM langref) that > would indicate that would allow distinct functions to have identical > addresses - so should we do something about this in the LLVM backend? > add a little padding? a nop instruction? (if we're adding an > instruction anyway, perhaps we might as well make it an int3?) This is also a problem with identical function merging in the linker, which link.exe does quite aggressively. The special case of zero-length functions seems less common than the more general case of merging, in both cases you will end up with a single implementation in the binary that has two symbols for the same address. For example, consider the following trivial program: #include <stdio.h> int a() { return 42; } int b() { return 42; } int main() { printf("a == b? %d\n", a == b); return 0; } Compiled with cl.exe /Gy, this prints: a == b? 1 Given that functions are immutable, it's a somewhat odd decision at the abstract machine level to assume that they have identity that is distinct from their value (though it can simplify debugging - back traces in Windows executables are sometimes quite confusing when you see a call into a function that is structurally correct but nominally incorrect). Given that link.exe can happily violate this guarantee in the general case, I'm not too concerned that LLVM can violate it in the special case. From the perspective of a programmer, I'm not sure what kind of logic would be broken by function equality returning true when two functions with different names but identical behaviour are invoked. I'm curious if you have any examples. David
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4