llvm-d

[Moritz Maxeiner]

On Tuesday, 2 April 2013 at 11:16:27 UTC, deadalnix wrote:
> On Friday, 29 March 2013 at 12:07:11 UTC, Moritz Maxeiner wrote:
>> Now regarding the fact that you say that solution will have 
>> the negative side-effect of making compile time and resource 
>> "explode": I have tested llvm-d on some of my old machines 
>> (inluding a first-gen intel atom underclocked to about 800 
>> Mhz) and llvm-d compilation was never noticable slow, or used 
>> considerable memory. But to either prove or contradict whether 
>> this is a noticable side-effect of that solution we'd need 
>> hard benchmarks.
>>
>
> DMD uses an huge amount of resource for CTFE, and leak a LOT of 
> memory. That is already known. Obviously, compiling this lib by 
> itself isn't going to trigger such issue.
>

I've not seen any mention about that under the "Documentation" 
category and I've only found posts about that after explicitly 
searching for that problem right now. I'm sorry for not knowing 
about that, but if that is such a critical problem, it may be 
sensible to document it in an article, e.g. "Compile time 
function evaluation", under dlang.org's "Documentation" category 
- I expected dmd to not use more memory for CTFE operations than 
D would for runtime operations.

Regardless of that, the llvm-d's D API will need to include all 
of the C API bindings anyway (however they may be done) and 
llvm-d's internal C bindings exist primarily for the use of the D 
API. If you only want the C bindings anyway, consider using 
deimos-llvm. I've forked it and am going to update it to 3.2 and 
3.3svn: https://github.com/Calrama/deimos-llvm

>
>> Another reason why the C bindings' enums and the D bindings' 
>> enums will stay seperated is for compatibility with 
>> deimos-llvm, which will be usable as a replacement for the 
>> internal C bindings for people who e.g. want a c header -> d 
>> module translation.
>
> You thrown away that with your module refactoring, so it is 
> kind of pointless to raise that point now.

This is the important part of that sentence:
>> which will be usable as a replacement for the internal C 
>> bindings

I don't use C header -> D module in llvm-d's internal C bindings, 
llvm-d's D API, however, can use either llvm-d's internal C 
bindings or (soon) deimos-llvm. I do not consider it pointless to 
raise the point that if you (the user, not you specifically) want 
to have a C header -> D module translation you can use 
deimos-llvm together with llvm-d's D API without llvm'd internal 
C bindings, that's all.