[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