similar to: [LLVMdev] Python bindings in tree

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

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 >

On 3/17/2012 4:14 PM, Anders Waldenborg wrote: > FYI: > > I've also been working on new python bindings. > > My bindings are written using ctypes (just like the in-tree > clang/cindex bindings). Most of Core.h is bound, and stuff from > ExecutionEngine.h, Analysis, BitReader, BitWriter. The have fairly > good test coverage (using nosetests). The ctypes definitions are

On Sun, Mar 18, 2012 at 09:52:12PM -0700, Gregory Szorc wrote: > The automatic generation of the Python ctypes interfaces using the Clang > Python bindings is pretty friggin cool! A nice side effect is that everything is added to the interface. So it is easy to add a small proxy over the lib that shows which parts of the llvm-c API that is exercised by the tests. (have that in my bindings)

I'd like to continue the discussion about minimum Python versions from the "Use multiprocessing instead of threading" thread in its own thread because I feel it warrants additional discussion. In that thread, we were discussing maintaining support for Python 2.4 and 2.5. The latest response is: On Fri, Nov 30, 2012 at 1:40 PM, Daniel Dunbar <daniel at zuster.org> wrote: >

On Mon, Mar 19, 2012 at 10:44 AM, Anders Waldenborg <anders at 0x63.nu> wrote: > > * Auto generated vs manual ctypes declarations. > This is purely a cosmetic difference, as we both take the same approach of registering functions on a global/shared ctypes library instance. I think automatic is the way to go (just as long as the automatically generated code is easy to diff when

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/1/12 12:57 PM, Gregory Szorc wrote: > > I believe LLVM should drop support for Python 2.4 and 2.5 for 2 main reasons: > > 1) Python 2.4 and 2.5 are end-of-lifed > 2) Python 3 is coming Entering the discussion a bit late, but I'd like to make a plug here for using Cython for any official Python bindings. There are numerous

On Wed, Jun 25, 2014 at 5:52 PM, Gregory Szorc <gregory.szorc at gmail.com> wrote: > As much as I like killing support for Python 2.6 and below, RHEL is > usually the blocker. They still have 2.4 under support. Only the RHEL that > was released a few weeks ago finally has 2.7. > Given the amount of complexity required to build LLVM & Clang (having the right compiler &

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

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

On Sat, Dec 1, 2012 at 2:08 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 2012-12-01 21:57, Gregory Szorc wrote: >> >> I'd like to continue the discussion about minimum Python versions from the >> "Use multiprocessing instead of threading" thread in its own thread because >> I feel it warrants additional discussion. > > ... >

http://llvm.org/docs/GettingStarted.html currently mentions Python 2.5 as a minimum required version. I'd like to use argparse <https://docs.python.org/dev/library/argparse.html> in a script and be able to test this script. This requires Python 2.7. This version has been around since 2010, and afaiu, is available on all modern platforms. Is there any reason not to change minimum required

On 2012-12-01 21:57, Gregory Szorc wrote: > I'd like to continue the discussion about minimum Python versions from the "Use multiprocessing instead of threading" thread in its own thread because I feel it warrants additional discussion. ... > For these reasons, I urge LLVM to drop support for Python older than 2.6. I would encourage requiring 2.7 (preferably the latest

Hi, I recompiled Dovecot with Lucene FTS to try to improve iOS 7 IMAP search speed. Unfortunately this does not seem to help. I have 60 mailboxes, totaling 300 MB; lucene-indexes is 30 MB in size. % doveadm mailbox status -t all '*' messages=16335 recent=0 unseen=1736 vsize=280049586 Searching for a single word which is present in two messages of one mailbox takes 40 seconds to

On Sat, Dec 1, 2012 at 2:14 PM, Eli Bendersky <eliben at google.com> wrote: > On Sat, Dec 1, 2012 at 2:08 PM, Dimitry Andric <dimitry at andric.com> wrote: > > On 2012-12-01 21:57, Gregory Szorc wrote: > >> > >> I'd like to continue the discussion about minimum Python versions from > the > >> "Use multiprocessing instead of

Hi, is there currently a way to create a cmpxchg instruction using the C bindings? I only found LLVMBuildAtomicRMW and LLVMBuildFence in the documentation. Regards, Christoph Grenz

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

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'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