similar to: [LLVMdev] Moving towards a singular pointer type

On Tue, Feb 17, 2015 at 8:56 AM, Antoine Pitrou <antoine at python.org> wrote: > > Hi, > > Dirkjan Ochtman <dirkjan <at> ochtman.nl> writes: > > > > As far as I understand, this change is wanted because the LLVM > > infrastructure derives no value from knowing the types, and there's a > > cost in terms of code spent to support all of it.

2016-01-20 1:11 GMT+02:00 Antoine Pitrou via llvm-dev < llvm-dev at lists.llvm.org>: > On Wed, 20 Jan 2016 00:47:56 +0200 > "Eddy B. via llvm-dev" <llvm-dev at lists.llvm.org> wrote: > > > > I would love to know your thoughts on this, and more specifically: > > Which of the 3 (byval(T), byval(N) and byval + dereferenceable + align) > > do you

On Thu, 12 May 2016 16:40:44 +0100 David Chisnall via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > The end result is that shortly after a release (sometimes every alternate release) is branched a load of downstream projects update to the new APIs, test things, and find a bunch of regressions that have been sitting in the tree for months. We then have to scrabble to bisect and try

Hal Finkel <hfinkel <at> anl.gov> writes: > > Do you require long-term cross-release ABI and/or API stability > from the C API that you're using? Do these > other projects? For the record, in llvmlite and Numba we don't require C API stability for two reasons: 1) the C API is not enough for us and we rely on bits of the C++ API 2) we also rely on other details

... and that's kind of annoying when I'm trying to debug something. Also, it doesn't seem like openssh.org lists the IRC channel (even though it's referenced) anywhere. Cheers, Dirkjan

On 12 May 2016 at 16:56, Kristof Beyls <Kristof.Beyls at arm.com> wrote: > In my opinion, it would be better overall for the LLVM project if > top-of-trunk is > tested as much as possible, if testing resources are so scarce that a > choice > has to be made between testing top-of-trunk or testing a release branch. > I agree that trunk is more important, with both of my

On Thu, May 24, 2012 at 12:53 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > One project I'd like to complete pretty soon is to go through the build > instructions, for mingw32, and see if I can't somehow create a mingw64 > build.  I believe the 32-bit platform is dying by the hour so I'm rather > eager to have a mingw64 version of LLVM/Clang.  Also, I'd love

​Hello all, I have written a code in llvmlite. Using command numba --dump-llvm example.py > example.ll I can have .ll file. However, using lli example.ll, I am stopped with error: 'main' function not found in module. Is there anyway at which it can be executed using lli? Thank you in advance Best -- This email was Anti Virus checked by Security Gateway. -------------- next part

Hi, I wrote yet another [1,2] Python binding for LLVM! I'm doing this because llvmlite has some serious limitations: 1) it cannot parse an existing IR, only create new modules [3], 2) it keeps its own representation of the IR (which is less memory efficient than the LLVM one), and 3) each llvmlite version supports a single LLVM version. Considering that my need is to load modules of hundreds

Thanks, happy to of confirmed. With that in mind, will use the AST modules provided by the languages (with the exception of libclang for C++). Antoine: Am aware of Numba, nice job there BTW. So is there a [decoupled] LLVM parser which I can use to read Python files and analyse objects (including computing their attributes in OO and setattr scenarios)? On Wed, Jul 1, 2015 at 10:23 PM, Antoine

On Wed, Jan 16, 2013 at 5:18 PM, Eli Bendersky <eliben at google.com> wrote: > I think it makes sense to create a bug report. Looking at the code of > LLParser::ParseGetElementPtr, the error handling appears to be very > simplistic, so I don't think there's any fundamental reason for not > doing a better job there. Filed http://llvm.org/bugs/show_bug.cgi?id=14965,

IIRC when LLVM came out a bunch of community-contributed parsers were available on your website. Essentially I want to read in a programming language, prune the AST until it contains only what I define as a "summary", then convert that AST to that of another language, before finally outputting [code-generating] a compilable/interpretable source [think boilerplate]. Would be good to

Yep we have our own parser <https://github.com/vinzenz/libpypa/> and we would love to see other people use it. When we looked around at some other Python parsers we didn't feel like any of them were easy to extract and use on their own, so we wrote our own and I think were able to keep ours well-separated. There are some things that make parsing Python somewhat difficult to do in a

> > the problem is that very few LLVM developers use or know anything about > Windows. > The only way for this to change is for people who do know and care about > Windows > to step forward, work on improving Windows support, and contribute their > Windows > viewpoint to design discussions etc. > As it is now, Windows users will quite likely drop LLVM because of the

Hello, I am a bit curious about the rationale for the current callback-based object cache API. For Numba, it would be easier if there would be a simple procedural API: - one method to get a module's compiled object code - one method to load/instantiate a module from a given piece of object code I manage to get around the callback-based API to do what I want, but it's a bit weird to work

Hi, In the past months, several options have been presented for making byval (and similar attributes, such as inalloca or sret) work with opaque pointers. The main two I've seen were byval(T) and byval(N) where N is the size of T. They both have their upsides and downsides, for example: byval(T) would be a type-parametric attribute, which, AFAIK, does not already exist and may complicate

> On Jan 12, 2017, at 5:03 AM, Antoine Pitrou via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, 9 Jan 2017 11:43:17 -0600 > Wei Ding via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Hi, >> >> I want an efficient way to implement function pow in LLVM instead of >> invoking pow() math built-in. For algorithm part, I am clear for the

LLVM Weekly - #57, Feb 2nd 2015 =============================== If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/57>. Welcome to the fifty-seventh issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex Bradbury](http://asbradbury.org).

On Sat, 17 Dec 2016 21:43:16 -0500 Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I agree that if an API user violates the API of a library, it is > appropriate for the library to abort with a fatal error. <unlurking> Is it? If you pass an invalid fd to the libc, it replies with a EBADF, it doesn't crash hard. Most mature libraries have guards

Hello, We are happy to release version 0.10.0 of llvmlite. llvmlite is a light-weight Python binding for LLVM (compatible with Python 2.7 as well as Python 3.4 and later). It stems from the needs of the Numba community and is geared towards creating JIT compilers. llvmlite is available both as source code and as binaries for a number of platforms. Source code is available on PyPI and Github: