llvm-d

[Moritz Maxeiner]

On Wednesday, 27 March 2013 at 15:29:19 UTC, deadalnix wrote:
> On Sunday, 24 March 2013 at 02:37:52 UTC, Moritz Maxeiner wrote:
>> On Sunday, 24 March 2013 at 01:35:28 UTC, Chris Cain wrote:
>>> On Saturday, 23 March 2013 at 21:19:14 UTC, Moritz Maxeiner 
>>> wrote:
>>>>
>>>> TLDR: Your example should now work, provided you fix what I 
>>>> previously mentioned. You can also look at 
>>>> sample/fibonacci.d which I used instead of your fac to 
>>>> confirm that you gist now works.
>>>>
>>>> - Moritz
>>>
>>> Awesome. Indeed, it now fully works (and JIT does work after 
>>> all! Thanks for showing me how to use that). Thanks for the 
>>> more interesting example in the README, it's extremely 
>>> helpful. And also thank you for taking some time to help with 
>>> the issues I was having.
>>
>> No problem, writing that fibonacci example forced me to read 
>> up Stuff about LLVM I need to know anyway (for making the D 
>> API)^^
>> Just one thing I forgot to mention: When you're using 
>> llvm.util.memory.toCString you'll need to take care of the 
>> allocated memory yourself, or you'll get memory leaks. The 
>> example is a special case as all the c strings need to be kept 
>> aroound until program termination, anyway (since LLVM's global 
>> context exists until then and all the c strings used by LLVM 
>> internally), but that's not the case with all LLVM C functions 
>> with c string args.
>>
>
> Question : why did you reorganize the modules ? They don't 
> match LLVM's .h filenames.
>
> Is that intended , if yes, why ?

Yes it is intended to be that way. Regarding the reasons for that 
decision:

Short answer:

Because in the case of the LLVM C API it makes things a lot 
easier and simpler to maintain, as well as trivial to add new 
parts for new LLVM versions.

Long answer:

1) The LLVM C API has headers which have very few lines of actual 
code (e.g. Linker.h which only contains one enum and one 
functions), making those into D modules seems wasteful.

2) Over versions of the LLVM C API headers appear and dissappear 
(e.g. Linker.h exists since 3.2, EnhancedDissassembly.h has been 
removed in trunk 3.3) and having them all around as D modules 
makes maintenence a lot more complicated.

3) Having all functions in a single compile time enum makes the 
runtime loading process a lot easier as you can generate all 
three steps ( 1. function pointer alias for every C function 2. 
function pointer variable for every function pointer alias 3. 
loading of the shared lib symbol into the function pointer for 
every function pointer) with but a few lines of codes, instead of 
having to write the names of all C functions three times. And 
since you can encode more information in that enum (an 
associative array in this case) adding more function is trivial: 
Simply add the function to the array in this manner: "NAME" : 
["SIGNATURE", "+", "VERSION"] and that's it (and if the function 
has been removed in said VERSION, change "+" into "-"). Since the 
MixinMap template (a CTFE version of the map function designed to 
get an array as its list and create D code for each of the items 
of said array based on a delegate function f) is used for the 
three steps described above no further code is needed.

TLDR: Supporting different versions of the LLVM C API takes 
considerably less effort this way and if there is a disadvantage 
to this approach big enough to outweigh that I can't see it.