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

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Tue Nov 29 10:37:32 PST 2016


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161129/225b7af7/attachment.html>


More information about the llvm-dev mailing list