[PATCH] Change representation of dllexport/dllimport

Nico Rieck nico.rieck at gmail.com
Mon Jul 8 06:18:39 PDT 2013


On 07.07.2013 21:35, Reid Kleckner wrote:
>  From the original 4 approaches, it looks like you went with #4 (new
> attributes).  Adding new visibilities (#3) is still on the table if people
> don't like the duplication between global variables and functions.  I'd
> like to hear from someone with more of a vested interest in the LLVM IL.

It's not exactly 4, because it changes the IR. Using 4 as written there 
wouldn't actually work anyway because static data members can have 
different linkage, too. Short of "abusing" linkage for this I see no way 
around extending the IR because globals don't have a flexible attribute 
system.

> In the original RFC, you suggested that someone might want to mix
> visibility and dll export control.  Is that a real use case?  I don't think
> PE DLLs can actually implement ELF's simple, C-like global namespace, so it
> sounds like you want to be able to emit ELF files using dllexport.

The "mixing" there (probably not the best choice of words) was meant 
like explained at <http://gcc.gnu.org/wiki/Visibility>. Though that 
approach doesn't actually work as nicely. There are codebases that apply 
such macros to class templates which makes no sense for dllimport. I 
just recently combed through libc++ to fix this.

> At this point, I've convinced myself that the export control stuff is best
> modeled as a new visibility.

You mean variant #3? I think this also partly depends on whether there's 
a need to export global aliases where the aliasee is not exported. 
Aliasing ctors/dtors use this, and inspecting the aliasee works fine 
there. But I just learned about the alias attribute.

> Regardless of attributes vs. visibilities, you shouldn't break the C API.
>   The C++ API is always in flux, but the C API is stable. [...]

Noted.

> If you do end up changing the grammar for global variables, you should add
> a "Syntax:" block to LangRef for globals like there is for most other
> language constructs.

Indeed. I actually wondered why there isn't one (and included an example 
instead).

-Nico



More information about the llvm-commits mailing list