[LLVMdev] new LTO C interface

[Nick Kledzik]

I've updated the header (enclosed).




On Feb 24, 2008, at 11:24 PM, Evan Cheng wrote:
> 1. __LTO__ -> LLVM_C_LTO
> 3. Rather than using underscore in function names, e.g. lt_foo_bar,  
> use capital letters and also start with prefix LLVM. e.g.  
> LLVMLTOFooBar.
As we discussed, this is interface is llvm independent.  It may even  
migrate out of include/llvm-c at some point.

> 2. Do we need those #include's?
We need stddef.h for size_t and stdbool.h for bool.

> 4. lto_codegen_release -> lto_codegen_release_memory to be clearer  
> and more consistent.
Renamed to lto_codegen_dispose()

> 5. Use C comments /* ... */?
Fixed.

> 6. Please start comments with capital letters and end sentences  
> with periods! Or perhaps not since it'll drive Chris nuts. :-)
Fixed.



On Feb 24, 2008, at 6:10 PM, Gordon Henriksen wrote:
>> #include <stdint.h>
>> #include <stdbool.h>
>
> Note that MSVC++ still doesn't support C99, and is a target for  
> LLVM. I'd suggest bool -> int and uint8_t* -> void* to resolve the  
> dependency.
I've change all the uint8_t to void.  I'm going to leave the use of  
bool.  The implementation of lto is all in C++, so it will build with  
MSVC++.  The only thing that might get tripped up by the use of bool  
in the interface is if someone tries to write a C (not C++) client  
(meaning a linker) using MSVC.


>> #include <stddef.h>
>>
>> extern const char*
>> lto_get_error_message();
>
> I've tried not to create thread-unsafe designs in the rest of the  
> bindings. I return a malloced error message by optional output  
> parameters and provide a generic dispose function  
> (LLVMDisposeMessage). Copying CFError's design might be smarter still.
There are other things not thread safe about the API.  Adding a  
string return would complicate the API.  And it is possible to make  
the API thread safe in the future by making lto_get_error_message()  
return a per-thread string.


>
>> extern bool
>> lto_module_is_object_file_in_memory(const uint8_t* mem, size_t  
>> length);
>>
>> extern bool
>> lto_module_is_object_file_in_memory_for_target(const uint8_t* mem,  
>> size_t length,
>>                                                const char*  
>> target_triplet_prefix);
>>
>> extern lto_module_t
>> lto_module_create_from_memory(const uint8_t* mem, size_t length);
>
> Why not void*? Saves casting.
Fixed.

>> //
>> // generates code for all added modules into one object file
>> // On sucess returns a pointer to a generated mach-o buffer and
>> // length set to the buffer size.  Client must free() the buffer
>> // when done.
>> // On failure, returns NULL (check lto_get_error_message() for  
>> details)
>> //
>> extern const uint8_t*
>> lto_codegen_compile(lto_code_gen_t cg, size_t* length);
>
> The return value should be non-const. free takes a void*, not a  
> const void*.
Fixed.

>> extern const char*
>> lto_module_get_target_triplet(lto_module_t mod);
>
> LLVM nomenclature is triple, not triplet.
Fixed.


>
>> extern uint32_t
>> lto_module_get_num_symbols(lto_module_t mod);
>>
>> extern const char*
>> lto_module_get_symbol_name(lto_module_t mod, uint32_t index);
>>
>> extern lto_symbol_attributes
>> lto_module_get_symbol_attribute(lto_module_t mod, uint32_t index);
>
> Why uint32_t instead of size_t?
I changed it to unsigned int.  It is not pointer size dependent.

>
>> //
>> // frees all memory for a code generator
>> // upon return the lto_code_gen_t is no longer valid
>> //
>> extern void
>> lto_codegen_release(lto_code_gen_t);
>
> Existing bindings use the term dispose to avoid any possible retain/ 
> release confusion.
Changed both _release functions to _dispose.


-Nick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080225/7fc6b7f5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lto.h
Type: application/octet-stream
Size: 6597 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080225/7fc6b7f5/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080225/7fc6b7f5/attachment-0001.html>