[PATCH] Change representation of dllexport/dllimport

[Stephen Lin]

On Sat, Jul 6, 2013 at 3:04 AM, Stephen Lin <swlin at post.harvard.edu> wrote:
>> 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.

Also, I could be wrong, but I'm pretty sure that there's nothing in
the Attributes interface that actually enforces that a string
attribute is used for a single LLVM target; I believe the word
"target-specific" is just used in the documentation to clarify that
string attributes are for things that are only meaningful in a subset
of configurations.

I'm fairly sure AArch64 and ARM backends share many string-based
attributes, for example, but that isn't a reason to promote them to IR
keywords.

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