[LLVMdev] RFC: ThinLTO Symbol Linkage and Renaming

[Duncan P. N. Exon Smith]

> On 2015-Jul-21, at 14:17, Teresa Johnson <tejohnson at google.com> wrote:
> 
> > 4.3.2  Renaming
> >
> > Since there may be multiple static functions from different modules with the same name before importing/promotion, or a global function which already has the same name, the promoted static functions must be renamed to avoid naming conflicts. It is important that the promoted definition in the original module is given the same name as the promoted reference in the importing module, so that the reference in the importing module can be satisfied by the original module at link time.
> >
> > To do the renaming consistently, we can include a module-specific identifier in the new name. The plugin step in phase-2 of ThinLTO (which builds the combined function index/summary) has visibility into all modules included in the ThinLTO build. It can simply number the modules and record the assigned module ID in the function summary information (either along with each function from that module, or along with the module name which will be shared in a module string table for efficiency). Then during promotion, the module ID in the combined function index/summary can be consulted and appended to the original name, along with an LLVM-specific suffix identifying this as a promoted static.
> >
> > For example,
> >         static void foo();  // In module with ID 1
> > originally has bitcode definition in module ID 1:
> >         define internal void @foo() // InternalLinkage
> > which becomes after promotion/renaming:
> >         define void @foo.llvm.1()  // ExternalLinkage, new suffix “.llvm.1”
> >
> > When we import a static definition into another module (say module ID 2), before promotion it has declaration:
> >         define internal void @foo()        // InternalLinkage, func summary info: from Module ID 1
> > which becomes after promotion/renaming:
> >         define available_externally void @foo.llvm.1()  // AvailableExternallyLinkage, new suffix “.llvm.1”
> >
> > If a reference is imported but not the definition, before promotion the new declaration is:
> >         declare internal void @foo() // InternalLinkage, func summary info: from Module ID 1
> > which becomes after promotion/renaming:
> >         declare void @foo.llvm.1()  // ExternalLinkage, new suffix “.llvm.1”
> >
> > Note that the new EliminateAvailableExternallyPass (under review) will change the linkage type from AvailableExternallyLinkage to ExternalLinkage on the declaration it leaves for any eliminated available externally definitions, which is consistent with the above behavior.
> >
> 
> I wonder whether a prefix would be better?
> 
> Is there a particular reason? I have a slight preference for suffix, but that could just be what I am used to from other compilers.

Nope, just thinking out loud.  Suffix sounds fine to me.