[llvm-commits] More C API wrappers

[Eric Christopher]

I'll look at these in the next day or so, just missed your ping.

-eric

On Sat, Nov 3, 2012 at 6:27 AM, James Y Knight <foom at fuhm.net> wrote:
> 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
>>
>