[PATCH][llvm-c] GlobalVariable: Expose ThreadLocalMode and ExternallyInitialized

[Moritz Maxeiner]

Hi Hans,

On 04/15/2013 11:19 AM, Hans Wennborg wrote:
> Hi Moritz,
>
> On Wed, Apr 3, 2013 at 8:25 PM, Moritz Maxeiner
> <moritzmaxeiner at googlemail.com> wrote:
>> Add four new functions and one new enum to the C API:
>>
>> LLVMGetThreadLocalMode - exposes GlobalVariable::getThreadLocalMode
>> LLVMSetThreadLocalMode - exposes GlobalVariable::setThreadLocalMode
>> LLVMIsExternallyInitialized - exposes
>> GlobalVariable::isExternallyInitialized
>> LLVMSetExternallyInitialized - exposes
>> GlobalVariable::setExternallyInitialized
>> LLVMThreadLocalMode - maps to GlobalVariable::ThreadLocalMode
> I think this looks good in general.

Thanks, I'd need someone to commit it for me, then, could
you do it please (if you have commit-acces)?

>
> Just wondering, in the interest of keeping the C API simple and
> stable, would it be enough to expose just something like
> LLVMIsThreadLocal / LLVMSetThreadLocal, or do you actually need the
> full enum?

The thing is that for many people I know (me included) using C++
is something they'd like to avoid (for whatever reason, explaining
mine would only lead to a rant on my part), which
means when using LLVM their only option (as they are using it
from neither C nor C++) is to use the C API.

E.g. I'd like to use LLVM from D (http://dlang.org) with LLVM's class
hierarchy. Since LLVM doesn't expose its classes' functions as virtual
(so they end up in a vtlb that D can use) I can't use an extern(C++)
interface and bind to the classes directly; ergo my only way left
is to mirror LLVM's hierarchy in D from what's available in the C API.

This is why I'd like for as much of the interface parts (*not* the internal
workings such as MemoryBuffer, APInt, StringRef, or the Target 
libraries, of course)
as possible to be available in the C API, including the ThreadLocalMode,
which I need in the C API to be able to mirror it in D.

On another note: The C API has not been exactly stable for the last few 
versions
of LLVM, anyway, e.g. enum items were removed and/or added on the inside
of enums, meaning the actual numbers of all enum items after that
insertion/deletion changed, resulting in breaking changes for non-C
languages that use the C API (It's not a breaking change for
C itself, but for everyone else using LLVM from non-C via the C API, it is).

Other than that I believe it to be more important for the C API to be closer
in exposed functionality to the C++ API than to not change - I'm also not
convinced that adding mechanical wrappers without any really new
semantics would lead to the C API becoming unstable (I may be wrong
here, of course, it's just how I see it right now).

Thanks for your time,
   Moritz