[PATCH] Change representation of dllexport/dllimport

[Stephen Lin]

> 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.

I'm not saying the latter at all, though, I'm just saying that the
attributes interfaces was refactored specifically to allow
special-purpose attributes to be added more easily and there doesn't
seem to be any reason for it not to be used in this case.

If this really isn't a Windows-specific feature, then it should be
named something more generic and the docs should describe it in a
platform and target-neutral way (with a possible note that it maps to
dllexport/dllimport on Windows, currently). If the semantics are not
that generic, then it ought to be a string-based attribute, which
every platform/target can implement separately without adding to a
single namespace and bitset.

This isn't a judgement on the value of the feature, it's just using
the attributes API in the manner that it was intended to be used, as
far as I understand it, which actually is a less invasive and simpler
change anyway.

Anyway, I could be wrong about the intended distinction between
string-based versus keyword attributes; I've cc'ed Bill Wendling, who
refactored the interface earlier this year, in case he has any input.

Thanks,
Stephen