search for: llvmattribute

...ta representation 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 inext...

...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 co...

...e functions are fixed, there would also be no way to set return value attributes). I'd like to propose that LLVM{Add,Remove}FunctionAttr be fixed to actually set the function attributes. And that a new API, LLVM {Add,Remove,Get}RetAttr be added, like: void LLVMAddRetAttr(LLVMValueRef Fn, LLVMAttribute PA); void LLVMRemoveRetAttr(LLVMValueRef Fn, LLVMAttribute PA); LLVMAttribute LLVMGetRetAttr(LLVMValueRef Fn); which will do the associated actions on the return value. If this is acceptable, I can submit a trivial patch that implements it. James PS: no comments on my last patch, not sure if it...

Thank you guys for the fast replies (!), now I can continue without worrying about it. -- Moritz On 2/17/2013 1:46 PM, Daniel Murphy wrote: > These values are masks for numbers. LLVMAlignment uses 5 bits, so the > mask is 31 (0b11111) and these bits (16-20) cannot be used by other > flags so the next available bit is 21. Same thing for LLVMStackAlignment. On 2/17/2013 1:53 PM,

While writing bindings to LLVM for another language via the c api I noticed that LLVMAlignment and LLVMStackAlignment do not use 1<<x like all the others, but 31<<x and 7<x respectively (see below, or here: http://llvm.org/docs/doxygen/html/Core_8h_source.html#l00148). It's likely this is as it is intended, but it does look out-of-place enough that I thought it might be a

...ve some guidance on naming issues. I do not propose to change the names or semantics of any existing functions. I propose to add the following declarations to <llvm-c/Core.h> along with corresponding definitions in $LLVM/lib/VMCore/Core.cpp: extern void LLVMAddReturnAttr(LLVMValueRef Fn, LLVMAttribute PA); extern void LLVMRemoveReturnAttr(LLVMValueRef Fn, LLVMAttribute PA); I also propose to add the corresponding OCaml functions to the "Operations on functions" section of the Llvm module in the OCaml bindings too, of course: (** [add_return_attr f a] adds the return parameter...

On Dec 21, 2010, at 00:43, Duncan Sands wrote: > > IIRC the function return value is considered to be the parameter with index 0. > The function itself is considered to be the parameter with index ~0U. Yes, that's what the documentation seems to say is the proper mode for indexing the return parameter, but when I set an attribute on the parameter with index zero, it gets applied to

...eRef ConstantVal); 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:

...sure how to adjust to this change. The AttributeSet object seems to store an array of Attribute(s) to construct an AttributeSet argument for addAttr I need to know the index of the Argument in the function? I can follow the lead of this code from Core.cpp: void LLVMAddAttribute(LLVMValueRef Arg, LLVMAttribute PA) { Argument *A = unwrap<Argument>(Arg); AttrBuilder B(PA); A->addAttr(AttributeSet::get(A->getContext(), A->getArgNo() + 1, B)); } Is this all I need? What does the A->getArgNo()+1 provide? The index of the argument in the function argument list+1? Is this change to...

...ruction > enum 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 f...

...>> 2) Removing old functions: if it's required -- after careful deliberation. >> 3) Modifying the signature of existing functions: no way. >> >> A couple of concrete examples: >> >> - Let's say you run out of space in an existing enum type (ahem, >> LLVMAttribute...). >> >> You should introduce new function names, taking a better type (perhaps >> some sort of set type, instead of a fixed-width integer...), mark the old >> ones deprecated so that users will update to the new functions. But, keep >> the old ones around so that ol...

...: 1) Adding new functions for new LLVM functionality: great. 2) Removing old functions: if it's required -- after careful deliberation. 3) Modifying the signature of existing functions: no way. A couple of concrete examples: - Let's say you run out of space in an existing enum type (ahem, LLVMAttribute...). You should introduce new function names, taking a better type (perhaps some sort of set type, instead of a fixed-width integer...), mark the old ones deprecated so that users will update to the new functions. But, keep the old ones around so that old code can keep working. There's no real...

...ttributeSet object seems to store an array of Attribute(s) to construct an AttributeSet argument for addAttr I need to know the index of the Argument in the function? > That's correct. > I can follow the lead of this code from Core.cpp: > > void LLVMAddAttribute(LLVMValueRef Arg, LLVMAttribute PA) { > Argument *A = unwrap<Argument>(Arg); > AttrBuilder B(PA); > A->addAttr(AttributeSet::get(A->getContext(), A->getArgNo() + 1, B)); > } > > > Is this all I need? What does the A->getArgNo()+1 provide? The index of the argument in the function a...

Is is possible since LLVM 2.7 to create multiple ExecutionEngine in the same process. Olivier. On Thu, Oct 7, 2010 at 6:41 PM, George Brewster <g at brewster.org> wrote: > Hi, > I'm working on an application that compiles using LLVM from multiple > threads. Currently, I'm doing this using one ExecutionEngine, but I've > observed that this does not seem to scale

Hi, I'm working on an application that compiles using LLVM from multiple threads. Currently, I'm doing this using one ExecutionEngine, but I've observed that this does not seem to scale well past a couple cores. I'd like to be able to get as much parallelism as possible in the compilation, and was wondering about using one ExecutionEngine per thread. The only information

...to implement this patch. 1) Add a definition for attribute 'noopt' in File llvm/IR/Attribute.h; 2) Teach how attribute 'noopt' should be encoded and also how to print it out as a string value (File lib/IR/Attributes.cpp); 2b) Add a new enum value for the new attribute in enum LLVMAttribute (File "include/llvm-c/Core.h"); 3) The new attribute is a function attribute; Teach the verifier pass that 'noopt' is a function attribute; Add checks in method VerifyAttributeTypes() (File lib/IR/Verifier.cpp): * NoOpt is a function-only attribute; * Assert if NoO...

...t; > 1) Add a definition for attribute 'noopt' in File llvm/IR/Attribute.h; > 2) Teach how attribute 'noopt' should be encoded and also how to print it > out > as a string value (File lib/IR/Attributes.cpp); > 2b) Add a new enum value for the new attribute in enum LLVMAttribute > (File "include/llvm-c/Core.h"); > 3) The new attribute is a function attribute; > Teach the verifier pass that 'noopt' is a function attribute; > Add checks in method VerifyAttributeTypes() (File lib/IR/Verifier.cpp): > * NoOpt is a function-only...

On Sun, Aug 16, 2015 at 10:34 PM, deadal nix via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > 2015-08-16 21:51 GMT-07:00 Eric Christopher <echristo at gmail.com>: >> >> The promise of stability. We don't promise that the C++ API will stay >> stable. >> > > > Why was that promise be made in the first place ? Has it been made in the >