search for: llvmattributes

I recently reimplemented the Attributes class. It now hides the data 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

Hi Bill, On 18/10/12 10:35, Bill Wendling wrote: > I recently reimplemented the Attributes class. It now hides the data 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

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

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

On Dec 21, 2010, at 11:33, james woodyatt wrote: > 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

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

On Tue, Oct 6, 2009 at 5:47 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Tue, Oct 6, 2009 at 2:13 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > > LLVMGetAttribute had a bug in it.  Here's the revised version of the patch Hi Kenneth! I wouldn't say that I'm the best reviewer, but I've been doing some work with the c bindings recently so

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:

Hi, I recently upgraded to the latest LLVM build and encountered a problem where the API for Argument::addAttr has changed. Previously it was Argument::addAttr(Attribute A) and I was able to work with this. The latest build has changed the method addAttr so that it requires an AttributeSet argument (Argument::addAttr(AttributeSet AS). I'm not sure how to adjust to this change. The

On Thu, Oct 8, 2009 at 2:39 AM, Erick Tryzelaar <idadesub at users.sourceforge.net> wrote: > On Tue, Oct 6, 2009 at 5:47 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >> On Tue, Oct 6, 2009 at 2:13 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >> >> LLVMGetAttribute had a bug in it.  Here's the revised version of the patch > > Hi

2015-08-17 13:47 GMT-07:00 David Blaikie <dblaikie at gmail.com>: > > > >> >> I'd propose that the only 100% strict rule should be that if the ABI/API >> changes, it is done in a way that *loudly* breaks old programs -- e.g. they >> fail to compile, link, or run (depending on how the other-lang wrappers are >> accessing the API functions) -- not

As someone who used the LLVM C API for an experiment back in 2009ish (porting the SBCL lisp compiler to target LLVM as a backend -- never finished), I thought it was great that LLVM provided the C API. I was sad that it wasn't properly updated to include support for all the newly introduced IR features, though. (E.g. atomics). I tried to send patches for some of that stuff a while later, but

On Jan 30, 2013, at 8:20 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote: > > Hi, > > I recently upgraded to the latest LLVM build and encountered a problem where the API for Argument::addAttr has changed. > > Previously it was Argument::addAttr(Attribute A) and I was able to work with this. > > The latest build has changed the method addAttr so

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

So.. I have investigated more on how a new function attribute to disable optimization on a per-function basis could be implemented. At the current state, with the lack of specific support from the pass managers I found two big problems when trying to implement a prototype implementation of the new attribute. Here are the problems found: 1) It is not safe to disable some transform passes in the

Andrea_DiBiagio at sn.scee.net wrote: > So.. > I have investigated more on how a new function attribute to disable > optimization on a per-function basis could be implemented. > At the current state, with the lack of specific support from the pass > managers I found two big problems when trying to implement a prototype > implementation of the new attribute. > > Here are the

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 >