[llvm-dev] RFC: Add an "interposible" linkage type (and implement -fsemantic-interposition)

[Hal Finkel via llvm-dev]

Hi Reid, Eric, 

I'd like to come back to this idea of splitting out interposible into its own bit separate from the base linkage type. I'm still not convinced that I see any structural advantage to doing this... 

Generally, the advantage of this kind of splitting is orthogonality, but there isn't much to be gained: We currently have four interposible linkage types (out of 11), and after this change we'll have five. For the others, we need to add validation code and diagnostics to disallow the forbidden combinations. Plus, two of these must be interposible (which means more validation code and diagnostics). 

On top of that, we'll lose an available subclass bit in GlobalValue: We currently use 4 bits to store the linkage type (as there are 11 of them). Adding one will fit in the same number of bits. But only two get removed if we factor out the interposibility, so we still need 4 bits for the base linkage type plus one more for the interposible bit. In short, because so few of the potential combinations are permitted, separating out interposibility will make our encoding less efficient. For backwards compatibility at the bitcode level, we'd need to do this anyway (i.e. explicitly represent the combined value set in one unified encoding space). 

In addition, there's engineering effort involved in updating APIs, etc. (mostly for me, but for everyone else too). I'm certainly willing to do that if we want to go down this route. Maybe I'm just missing some bigger-picture advantages. 

Thanks again, 
Hal 

----- Original Message -----

> From: "Reid Kleckner" <rnk at google.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Eric Christopher" <echristo at gmail.com>, "llvm-dev"
> <llvm-dev at lists.llvm.org>
> Sent: Tuesday, November 29, 2016 12:37:32 PM
> Subject: Re: [llvm-dev] RFC: Add an "interposible" linkage type (and
> implement -fsemantic-interposition)

> On Tue, Nov 29, 2016 at 10:02 AM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> > So we're all on the same page, our current encodings are:
> 

> > External: 0
> 
> > WeakAny: 16
> 
> > Appending: 2
> 
> > Internal: 3
> 
> > LinkOnceAny: 18
> 
> > ExternalWeak: 7
> 
> > Common: 8
> 
> > Private: 9
> 
> > WeakODR: 17
> 
> > LinkOnceODR: 19
> 
> > AvailableExternally: 12
> 

> > And the new encodings would be:
> 

> > External: 0
> 
> > External + Interposible: 20
> 
> > Weak + Interposible: 16
> 
> > Appending: 2 [interposible N/A]
> 
> > Internal: 3 [never interposible]
> 
> > LinkOnce + Interposible: 18
> 
> > ExternalWeak: 7 [always interposible]
> 
> > Common: 8 [interposible N/A]
> 
> > Private: 9 [never interposible]
> 
> > Weak: 17
> 
> > LinkOnce: 19
> 
> > AvailableExternally: 12 [never interposible]
> 

> > With the mappings:
> 

> > [Old] -> [New]
> 
> > External -> External
> 
> > WeakAny -> Weak + Interposible
> 
> > LinkOnceAny -> LinkOnce + Interposible
> 
> > WeakODR -> Weak
> 
> > LinkOnceODR -> LinkOnce
> 

> > Is this what you had in mind?
> 

> > Thanks again,
> 
> > Hal
> 
> Exactly!

> The verifier should check that users aren't making invalid things
> like interposable internal/available_externally functions.

> I'm not exactly sure when ExternalWeak applies and how we should
> model its interposability. I guess it would always be interposable
> to avoid special cases.
-- 

Hal Finkel 
Lead, Compiler Technology and Programming Languages 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161130/22466d05/attachment.html>