[PATCH] D31352: Linker: Mark non-prevailing dllexport symbols as exported with a linker flag.

Reid Kleckner via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 29 13:28:36 PDT 2017


On Sun, Mar 26, 2017 at 7:52 AM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> Reid Kleckner <rnk at google.com> writes:
>
> > On Fri, Mar 24, 2017 at 2:14 PM, Rafael Avila de Espindola <
> > rafael.espindola at gmail.com> wrote:
> >
> >> This has the disadvantage that now two parts of the llvm are responsible
> >> for converting dllexport to linker directives (even if they share the
> >> function they call).
> >>
> >> I would prefer your previous solution or for the linker to keep a
> >> dllexport declaration in the IR.
> >>
> >
> > That proposal has the disadvantage that it breaks StripFunctionPrototypes
> > and GlobalDCE. I thought we covered that in the discussion somewhere.
>
> I would say it requires StripFunctionPrototypes and GlobalDCE to be
> changed.
>
> Even with this patch we have to change other passes.
>
> For example, if the inliner inlines the last use of a linkonce_odr, it
> has to keep the declaration if it is dllexport.
>

We're talking about changing the semantics of dllexport on declarations,
though, and the inliner can't inline a declaration.

In practice, we give all dllexport definitions a non-discardable linkage,
so the inliner doesn't normally have to do anything.

What do you think should happen if the user feeds LLVM a discardable
dllexport inline function? It doesn't seem reasonable for LLVM to inline
the function, delete the body, and leave behind a dllexport declaration
that will generate an -export .drective referencing an undefined symbol.
Maybe we should consider rejecting exported discardable things in the
verifier?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170329/3a3caac8/attachment.html>


More information about the llvm-commits mailing list