[llvm-commits] More C API wrappers

[James Y Knight]

Ping^2?

Am I doing it wrong? Is there another preferred way to submit patches?

James

On Oct 27, 2012, at 5:28 PM, James Y Knight wrote:

> Ping?
> 
> On Oct 19, 2012, at 5:04 PM, James Y Knight wrote:
> 
>> 
>> On Oct 19, 2012, at 4:40 PM, Eric Christopher wrote:
>> 
>>> On Fri, Oct 19, 2012 at 12:49 PM, James Y Knight <foom at fuhm.net> wrote:
>>>> This patch adds some more wrappers to the llvm-c API.
>>>> 
>>> 
>>> Can you give a bit more description of why you need these? We add
>>> items to the C API on an "as needed" basis.
>> 
>> I'm working a little bit more on the LLVM backend of SBCL (a common lisp compiler/runtime), which I last worked on for about 2 weeks at the end of 2009 (I don't have much time to work on this, you might be able to tell). Some of the code from back then is here: http://repo.or.cz/w/sbcl/llvm.git
>> 
>> It uses common-lisp wrappers of the LLVM-C API.
>> 
>> 
>> Going through the list of things I added:
>>>   LLVMBuildFence
>>>   LLVMBuildAtomicCmpXchg
>>>   LLVMBuildAtomicRMW
>>>   LLVMGetAtomicOrdering/LLVMSetAtomicOrdering
>>>   LLVMGetSynchronizationScope/LLVMSetSynchronizationScope
>> 
>>>   Also, fix LLVMGetVolatile/LLVMSetVolatile to handle the new
>>>   memory instructions.
>> 
>> 
>> I need support for compiling atomic operations. In 2009, they were intrinsics. Now they're separate instructions. LLVMBuild* for the new instructions, LLVM{Get/Set}{AtomicOrdering,SynchronizationScope} both for the new instructions and for creating atomic Load/Store instructions.
>> 
>> 
>> The rest of the additions I had wrapped myself back in 2009, but I figured I ought to contribute them upstream instead:
>> 
>>>   LLVMParseAssemblyString
>> 
>> This is to allow inserting a bit of raw llvm-asm into an otherwise-programamtically built module, I use it for some support routines emitted by the compiler.
>> 
>>>   LLVMPrintModuleToString
>>>   LLVMPrintTypeToString
>>>   LLVMPrintValueToString
>> 
>> It's useful to be able to print these types to help debug what's going on.
>> 
>>>   LLVMIntPtrTypeInContext
>> 
>> This seems like a pretty obvious omission: LLVMIntPtrType is already wrapped, but only with a version which uses the global context. Everything else that uses a context has an InContext version.
>> 
>> 
>> Thanks,
>> James
>