[PATCH] Change representation of dllexport/dllimport

[Robinson, Paul]

My linker guys say that visibility and dllimport/dllexport are orthogonal, therefore I conclude that dllimport/dllexport should not be modeled as visibility values.  It may be that some combinations of visibility and import/export don't make sense, but that doesn't mean you have to make it syntactically impossible to express them.  (That's what semantic checking is for.)

My linker guys are also agitating to make -fvisibility=hidden the default for our platform, which caused me to double-take at the thought of dllexport'ing a hidden symbol but they say it is a reasonable thing to do.  We already default to -fPIC so we'd get a bit of a win by defaulting to -fvisibility=hidden as well (references to hidden symbols don't have to go through the GOT).  I'm not saying we want it to be the default for everybody, but rather it should be target-specific.

I think this was settled previously in the thread but I thought I'd chime in that we use dllimport/dllexport and we are an ELF/non-Windows target.

From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Reid Kleckner
Sent: Wednesday, September 11, 2013 9:24 AM
To: Nico Rieck; Chandler Carruth
Cc: reviews+D1110+public+872068f434b7231c at llvm-reviews.chandlerc.com; llvm-commits
Subject: Re: [PATCH] Change representation of dllexport/dllimport

On Wed, Sep 11, 2013 at 11:38 AM, Nico Rieck <nico.rieck at gmail.com<mailto:nico.rieck at gmail.com>> wrote:
On 09.09.2013 18:36, Reid Kleckner wrote:
How's this patch doing?  It's come up on the mailing lists a few times, so I thought I'd ping. :)

I guess it's mainly lacking more feedback about which variant to pursue. As reasoned before, I don't really like conflating the term "visibility" with dllimport (it would also require making -fvisibility=hidden the default). But opinions on this have been very scarce.

As for opinions, everyone I talked to locally felt that if the export controls can't be combined with visibility, then there's no reason to make the invalid combinations representable in IR.  Maybe they'll chime in.

I don't see a need to make -fvisibility=hidden the default, either.  I don't want to use the same enum for default visibility and dllexport.  It seems to me that default visibility should be the platform default visibility when linking DSOs, and dllexport should force a symbol into .drectve and possibly into .dynsym for ELF, if that's representable in a .o file.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130911/30406cb0/attachment.html>