[PATCH] Change representation of dllexport/dllimport

[Óscar Fuentes]

Hello Stephen,

Stephen Lin <swlin at post.harvard.edu> writes:

>> dllexport/dllimport is not target-dependent ("target" meaning "a LLVM
>> target") and IIRC it is used by other OSs than Windows (OS/2 or whatever
>> is named now, to name one.) The Windows group of OSs itself runs on at
>> least two LLVM targets: x86(_64) and ARM (PowerPC, Alpha and MIPS on the
>> past.) That list may grow in the future.
>
> Yes, I'm aware and I thought about proactively mentioning that.
> Basically, regardless of how you define "target", the attributes as
> currently defined don't seem to have any meaningful semantics in most
> compilation configurations so it doesn't really seem necessary to
> promote them to target-indepedent attributes (which, for the most
> part, concern semantics that all targets and configurations must
> ostensibly handle.
>
>>
>> Finally, dllexport/dllimport is similar to features on other
>> OSes/toolchains. Visibility attributes on GCC, for instance. Maybe the
>> attribute can be used to (re)implement the visibility attribute, because
>> they are quite similar conceptually.
>
> If it's really the same thing, then it seems better to rename it to
> something which is platform neutral and simply have it map to
> dllexport/dllimport for Windows targets.

dllexport/dllimport is, to all practical purposes, an standard way of
saying that a symbol is exported/imported from a dynamic load library
(or shared object.) The GCC devs themselves explain their visibility
attributes on terms of "we want dllexport/dllimport on ELF":

http://gcc.gnu.org/wiki/Visibility

For the reasons mentioned on the reference above, marking symbols to be
exported (which implicitly means that you are hiding other symbols;
that's the really interesting part) is something very convenient and for
that reason it is a feature that will grow in usage across multiple
platforms. (Wish LLVM used visibility attributes instead of exporting
thousands of autogenerated and private symbols on *nix, and making it
possibly to build LLVM as a set of shared libraries on Windows.)

I'm not saying that dllexport/dllimport *must* have its own specific
attribute, maybe you are right and it deserves to be a string-based
attribute. What I'm disputing is the claim that dllexport/dllimport is a
Windows-specific feature that does not deserve attention by LLVM
developers working on other OSs.

> If that's not appropriate, however, then it's all the more reason to
> make it a string-based attribute; otherwise, every type of visibility
> supported by every type of OS would have to get its own LLVM IR
> keywords, each of which would individually only be relevant for a
> minority of compilation configurations.