similar to: llvm.canonicalize.f64 unavailable?

Hello, I haven't found any relevant info in the docs about this. I'm trying to build LLVM 3.7.1 on OS X but it fails in the configuration phase. Here are the relevant parts of the output: $ cmake -DCMAKE_INSTALL_PREFIX=/Volumes/HD2/jenkins/workspace/LLVMDev/label/osxbuild/miniconda/envs/_build -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=host -DLLVM_INCLUDE_TESTS=OFF

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

Hello, LTO is currently the only library which is always built as shared, even under Windows. This actually seems to lead to failure using LLVM in another project under Windows, at least for me (the error message complains about "LTO-NOTFOUND.OBJ"). Switching it to a static library fixes the issue (again, at least for me under Windows). The change was made in:

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.

Hello, Am I right in thinking that MCJIT doesn't support thread-local variables (at least not on Linux x86-64)? Is there any plan or pending PR to support it (either in MCJIT or in ORC)? Thank you, Regards Antoine.

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

I had tried this in https://reviews.llvm.org/D8815, but we've since switched to a home grown TLS implementation, so I currently don't have a need for this. On Thu, Aug 18, 2016 at 12:17 AM, Alex Denisov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > /cc Lang Hames > > > On 17 Aug 2016, at 19:27, Antoine Pitrou via llvm-dev < > llvm-dev at lists.llvm.org>

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

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

Good point. The same argument seems to apply to copy() too so I suppose it depends how strict we want to be about it. From: fglaser at apple.com [mailto:fglaser at apple.com] On Behalf Of escha at apple.com Sent: 11 April 2016 20:55 To: Daniel Sanders Cc: Alex Rosenberg; llvm-dev at lists.llvm.org; Carlos Liam Subject: Re: [llvm-dev] Implementing a proposed InstCombine optimization On Apr 11,

> 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

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

On Tue, 11 Oct 2016 13:46:35 -0700 Michael Kuperstein via llvm-dev <llvm-dev at lists.llvm.org> wrote: > To the best of my understanding - because we want to be able to bootstrap > clang with the system compiler that ships with various linux and BSD > distributions. > Windows has no equivalent concept. To elaborate on this: if you want to produce binaries compatible with old

Hi, On Thu, 28 Jul 2016 09:32:18 -0700 Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I think David and I are probably the most familiar with how WinEH works in > LLVM, but I don't think either of us has time to prepare a talk for the dev > meeting. I'm trying to prepare a talk on supporting the MS debug info > format in LLVM this year. That said,

On Tue, 04 Oct 2016 15:29:14 +0000 Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I'm not familiar with the release process, but couldn't most of the > concerns raised in this thread be addressed by shipping prebuilt binaries > for these big platforms with older toolchains? That wouldn't address the cases where people use different build options (e.g.

> I am not entirely sure this is safe. Transforming this to an fsub could change the value stored on platforms that implement negates using arithmetic instead of with bitmath (such as ours) I think it's probably safe for IEEE754-2008 conformant platforms because negation was clarified to be a non-arithmetic bit flip that cannot cause exceptions in that specification. However, I'm sure

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

> On Jan 12, 2017, at 12:58 PM, Friedman, Eli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/12/2017 9:33 AM, Mehdi Amini via llvm-dev wrote: >>> 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

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

I am not entirely sure this is safe. Transforming this to an fsub could change the value stored on platforms that implement negates using arithmetic instead of with bitmath (such as ours) and either canonicalize NaNs or don’t support denormals. This is actually important because this kind of bitmath on floats is very commonly used as part of algorithms for complex math functions that need to get