search for: llvmgetfunctionattr

...ion inside of an opaque class. In the near future, we will be extending this class to encompass many other attributes. The changes pose one problem, however. The C-API still uses the old data representation for passing along the Attributes class. In particular, these two functions: LLVMAttribute LLVMGetFunctionAttr(LLVMValueRef Fn); LLVMAttribute LLVMGetAttribute(LLVMValueRef Arg); return the LLVMAttribute, which is an enum that happens to be the internal bit representation of the Attributes object. This is bad for several reasons, not the least of which is that it's completely inextensible (e.g., we do...

...paque class. In the near future, we will be extending this class to encompass many other attributes. > > The changes pose one problem, however. The C-API still uses the old data representation for passing along the Attributes class. In particular, these two functions: > > LLVMAttribute LLVMGetFunctionAttr(LLVMValueRef Fn); > LLVMAttribute LLVMGetAttribute(LLVMValueRef Arg); > > return the LLVMAttribute, which is an enum that happens to be the internal bit representation of the Attributes object. This is bad for several reasons, not the least of which is that it's completely inextensibl...

The LLVMAddFunctionAttr and LLVMRemoveFunctionAttr are busted: they actually set the return value's attributes, not the function's attributes. There seems to be no C API for actually setting the function attributes. LLVMGetFunctionAttr, however, does correctly return the function attributes, not the return value's attributes. There is no C API for getting the return value attributes. (And if the above functions are fixed, there would also be no way to set return value attributes). I'd like to propose that LLVM{Add,...

...al); This seems okay with me, but there really should be an LLVMInstruction enum defined instead of a raw unsigned value. Could you also add a LLVMConstExpr that wraps ConstantExpr::get? +int LLVMHasInitializer(LLVMValueRef GlobalVar); Seems fine to me. I can commit this now. +LLVMAttribute LLVMGetFunctionAttr(LLVMValueRef Fn); +LLVMAttribute LLVMGetAttribute(LLVMValueRef Arg); I've never really done much with attributes. What are you using this for?

On Tue, Oct 6, 2009 at 2:13 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > My front-end is sync'd with the trunk now, and working well, but it > required some additional functions exposed in the C bindings.  I > hereby submit them for review and approval for inclusion in the trunk. > LLVMGetAttribute had a bug in it. Here's the revised version of the patch

My front-end is sync'd with the trunk now, and working well, but it required some additional functions exposed in the C bindings. I hereby submit them for review and approval for inclusion in the trunk. -------------- next part -------------- A non-text attachment was scrubbed... Name: cbindings.patch Type: application/octet-stream Size: 7269 bytes Desc: not available URL:

...num defined instead of a raw unsigned value. Could you also add a > LLVMConstExpr that wraps ConstantExpr::get? That shouldn't be a problem. > > > +int LLVMHasInitializer(LLVMValueRef GlobalVar); > > > Seems fine to me. I can commit this now. > > > +LLVMAttribute LLVMGetFunctionAttr(LLVMValueRef Fn); > +LLVMAttribute LLVMGetAttribute(LLVMValueRef Arg); > > > I've never really done much with attributes. What are you using this for? > In order to do away with include files, I'm supporting importing modules in bitcode form. To call a function from an impo...