[cfe-dev] [llvm-dev] RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR

[John McCall via cfe-dev]

> On Mar 11, 2016, at 8:33 AM, Reid Kleckner <rnk at google.com> wrote:
> On Thu, Mar 10, 2016 at 10:32 PM, John McCall via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> I mean, I’ve never really liked ELF’s stance on symbol interposition, but taking it as given, I’m not sure I agree that it’s reasonable to carve out virtual functions as a general exception.
> 
> Given that LLVM does IPO (inlining, funcattrs) on symbols that can be interposed on ELF, we already don't support interposability very well:
> https://llvm.org/bugs/show_bug.cgi?id=23501 <https://llvm.org/bugs/show_bug.cgi?id=23501>
> 
> Adding another exception for virtual functions, especially under an off-by-default flag, doesn't seem like a big deal.

Okay, so, it sounds to me like LLVM basically treats strong definitions as protected, then.  Should we just formalize that?

I guess the proposal here would be:
  1. Remove protected visibility from LLVM.  (Or deprecate it as equivalent to default.)
  2. Teach the ELF emitter to emit non-hidden strong definitions using ELF protected visibility.
  3. Teach the ELF emitter to emit non-hidden weak definitions using ELF default visibility (unless they’re unnamed_addr?).

GCC must do *some* inlining between strong definitions.  Do you know what their rule is?  Is it just a C++ thing?

John.

>  
> Isn’t there some global flag to make (non-weak?) definitions use protected visibility by default?  Wouldn’t using that be an overall performance win anyway?
> 
> Joerg mentioned -Bsymbolic, but I'm surprised that I don't see people use -Bsymbolic-functions more often. C++ has the ODR, so we can say that all definitions of the same (C++!) function must be equivalent, and it doesn't matter which you call. Programs very rarely rely on function pointer identity across DSOs, and it already isn't preserved on a number of platforms (MSVC does ICF). Typically only global data needs to be coalesced across DSOs, so that things like static data members of templates and static locals in inline functions work.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160311/114b214d/attachment.html>