similar to: AtomicCmpXchg in C bindings

Hello, Am Donnerstag, 15. März 2012, 21:15:02 schrieb Gregory Szorc: > There was some talk on IRC last week about desire for Python bindings to > LLVM's Object.h C interface. So, I coded up some and you can now find > some Python bindings in trunk at bindings/python. Currently, the > interfaces for Object.h and Disassembler.h are implemented. FYI: I recently startet working on

Hallo, I worked on how to handle the distinction between variadic defines and uses and my current solution is this: I introduce a new dag item in Instruction called VariadicOperandList, which by default is undefined. It keeps a marker variable_* and all operands which are placeholders for variable lists (like 'reglist' on ARM). I think it's the cleanest solution to keep them in a

There was some talk on IRC last week about desire for Python bindings to LLVM's Object.h C interface. So, I coded up some and you can now find some Python bindings in trunk at bindings/python. Currently, the interfaces for Object.h and Disassembler.h are implemented. I'd like to stress that things are still rough around the edges, so use at your own risk. I intend to smooth things over in

Hi all, when e.g. accessing a global variable residing in a structure, the c++API code looks like: std::vector<Constant*> const_ptr_183_indices; const_ptr_183_indices.push_back(const_int32_172); const_ptr_183_indices.push_back(const_int32_184); const_ptr_183_indices.push_back(const_int64_175); Constant* const_ptr_183 = ConstantExpr::getGetElementPtr(gvar_struct_foo,

Am Mittwoch, 26. September 2012, 11:18:20 schrieb Jakob Stoklund Olesen: > Hi Christoph, > > As you noticed, MCInstrDesc doesn't distinguish between variadic uses and > defs. Since variadic instructions will always require some kind of special > handling, it doesn't seem worthwhile to make the model more detailed. I don't see what makes them so different from other

Hello all, I notice in previous gsocs of LLVM , there is no projects about language bindings for LLVM. Does that mean it has lower priority than other projects? Current python bindings for LLVM in the trunk are far from complemte. So I would like to improve python bindings for LLVM this summer if possible. My work will be based on llvm-py project ( http://code.google.com/p/llvm-py/). I obtained

Hi all, The C++11 (& C11) compare_exchange functions with explicit memory order allow you to specify two sets of semantics, one for when the exchange actually happens and one for when it fails. Unfortunately, at the moment the LLVM IR "cmpxchg" instruction only has one ordering, which means we get sub-optimal codegen. This probably affects all architectures which use

Am Freitag, 23. März 2012, 19:44:19 schrieb Baozeng: > Hello all, > I notice in previous gsocs of LLVM , there is no projects about language > bindings for LLVM. Does that mean it has lower priority than other > projects? Current python bindings for LLVM in the trunk are far from > complemte. So I would like to improve python bindings for LLVM this summer > if possible. My work

On Sep 24, 2012, at 6:39 PM, Christoph Grenz <christophg+llvm at grenz-bonn.de> wrote: > Is it possible to extend LLVM to check if 'variable_ops' is in 'ins' and/or > 'outs' in tablegen, so that MCInstrDesc could provide something like > hasVariadicDefs() and hasVariadicUses()? > > That way handling variadic instructions when disassembling would be

Hello, I'm currently working on a rich disassembler for some ARM/Thumb environment. I wanted to keep most classes independent of the architecture, so I use MCInstrInfo and MCInstrAnalysis to find branch instructions (and other instructions writing to the program counter) and to differentiate between register definitions and uses to track all instructions the branch depends on. This works

Am Dienstag, 23. April 2013, 22:50:51 schrieben Sie: > [...] > Giving more-than-expected precision can be just as bad for the user as less. > It tends to come up in situations where the optimization would break some > symmetry, the same way that aggressively forming FMAs can break user code. > [...] > > It boils down to the fact that giving excess precision in >

On Apr 23, 2013, at 3:33 PM, Christoph Grenz <christophg+llvm at grenz-bonn.de> wrote: > Hello, > > Am Dienstag, 23. April 2013, 13:26:19 schrieb Owen Anderson: >> That's a pretty seriously unsafe floating point optimization. It could be >> done in fast-math mode, but I doubt we currently do it. > > I just saw this thread and wonder why it's

Hello, Am Dienstag, 23. April 2013, 13:26:19 schrieb Owen Anderson: > That's a pretty seriously unsafe floating point optimization. It could be > done in fast-math mode, but I doubt we currently do it. I just saw this thread and wonder why it's "seriously" unsafe? I see only one problematic corner case. For x >= 0.0 the result cannot lose precision. For x = NaN the

Hello, I didn't see any section on this site for LLVM language bindings. There is http://llvm.org/ProjectsWithLLVM/ but that seems to be more about self-contained applications of LLVM. I think it would be useful to add a page (or section to an existing page) if you all agree. My binding is https://github.com/keithshep/llvm-fs and I know that there are many others. Best, Keith

I finally got around to adding these. The patch is posted in a pull request on my copy of llvm.git: https://github.com/jrk/llvm/pull/3 and a simple test with OCaml is here: https://gist.github.com/3948460 Feedback welcome. On Sep 14, 2012, at 7:53 PM, Jonathan Ragan-Kelley <jrk at csail.mit.edu> wrote: > Forgive me if I'm missing something obvious, but it seems that a >

Forgive me if I'm missing something obvious, but it seems that a number of core instructions—I'm specifically running in to `atomicrmw`, `fence`, and `cmpxchg` at the moment—cannot be constructed from the C bindings, and are therefore also inaccessible to the OCaml bindings. There are opcodes for each of these in the llvm-c/Core.h, but there seems to be no way to construct them. Is there

At Fri, 16 Mar 2012 14:12:08 +0100, Christoph Grenz wrote: > > Hello, > > Am Donnerstag, 15. März 2012, 21:15:02 schrieb Gregory Szorc: > > There was some talk on IRC last week about desire for Python bindings to > > LLVM's Object.h C interface. So, I coded up some and you can now find > > some Python bindings in trunk at bindings/python. Currently, the >

Hi, I'm having a play with LLVM to implement a custom language (for my intellectual curiosity only). I'm wondering how, when using IRBuilder, one can can it to emit a recursive type definition? The code for TypeBuilder explicitly states that it doesn't handle recursive types... I'm after being able to emit, programmatically, stuff like the Named Types example in the Language

On Sat, Aug 22, 2020 at 10:59:51AM +0200, Nicolai Hähnle wrote: > On Sat, Aug 22, 2020 at 2:52 AM Joerg Sonnenberger via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Aug 21, 2020 at 11:51:18PM +0200, Nicolai Hähnle wrote: > > > On Tue, Aug 18, 2020 at 1:27 AM Joerg Sonnenberger via llvm-dev > > > <llvm-dev at lists.llvm.org> wrote:

On Fri, Aug 21, 2020 at 11:51:18PM +0200, Nicolai Hähnle wrote: > On Tue, Aug 18, 2020 at 1:27 AM Joerg Sonnenberger via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > On Fri, Aug 14, 2020 at 10:42:02AM -0700, JF Bastien via llvm-dev wrote: > > > We (C, C++, and LLVM) are generally moving towards supporting FP as a > > > first-class thing with all atomic