similar to: MCJIT on cross-toolchain?

> On 18 Nov 2019, at 22:11, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 17:06, Sergej Jaskiewicz <jaskiewiczs at icloud.com <mailto:jaskiewiczs at icloud.com>> wrote: >> >> >> >> On 18 Nov 2019, at 19:55, Peter Smith <peter.smith at linaro.org> wrote: >> >> On Mon, 18 Nov 2019 at 15:23, Sergej

> On 18 Nov 2019, at 19:55, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 15:23, Sergej Jaskiewicz <jaskiewiczs at icloud.com <mailto:jaskiewiczs at icloud.com>> wrote: >> >> Hi Peter, >> >> Thanks for your response. >> >> On 18 Nov 2019, at 17:44, Peter Smith <peter.smith at linaro.org> wrote:

Hi Peter, Thanks for your response. > On 18 Nov 2019, at 17:44, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 12:32, Sergej Jaskiewicz via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> There’s this bug: https://bugs.llvm.org/show_bug.cgi?id=38468

Hello, LLVM community. I've built a cross-toolchain on Windows and I'm now trying to run unit tests for the LLVM libraries. I used Ninja as a build system and MSVC as host compiler without an issue, but when I try to run 'ninja check-llvm-unit', I get the following error: llvm-lit.py: C:/Users/sergej/Developer/llvm-project/llvm\utils\lit\lit\TestingConfig.py:102: fatal: unable

There’s this bug: https://bugs.llvm.org/show_bug.cgi?id=38468. I’ve managed to track it down to a configuration issue. The thing is that in order for libunwind to be usable on ARM Linux, it should be built with the -funwind-tables flag. This flag is conditionally set here: https://github.com/llvm/llvm-project/blob/master/libunwind/CMakeLists.txt#L294, if the compiler “supports” it. However, the

On 06/23/2016 12:56 PM, Craig Topper wrote: > Can you check what value "getHostCPUName" returned? getHostCPUName() = skylake > > On Thu, Jun 23, 2016 at 9:53 AM, Frank Winter via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > With LLVM 3.8 the JIT compiler engine generates an AVX512 > instruction although I

Hello, On the appended reasonably simple test case that has an fmul/fadd sequence on <8 x float> vector types, I don't see the x86-64 code generator (with cpu set to haswell or later types) turning it into an AVX2 FMA instructions. Here's the snippet in the output it generates: $ llc -O3 -mcpu=skylake --------------------- .LBB0_2: # =>This Inner

Hi all! After booting the server I have this message: irq 50: nobody cared (try booting with the "irqpoll" option) Call Trace: <IRQ> [<ffffffff800c17e6>] __report_bad_irq+0x30/0x7d [<ffffffff800c1a19>] note_interrupt+0x1e6/0x227 [<ffffffff800c0f15>] __do_IRQ+0xbd/0x103 [<ffffffff8006e249>] do_IRQ+0x13f/0x14d [<ffffffff8006ca05>]

Hi All, Could anyone tell me, how to correctly install MySQL4.1 on Centos 5 ? By default Centos 5 comes with mysql5? If I will compile mysql4 from sources to separate prefix, some features may be unavailable (unix sockets for example). I?m moving some critical application (online booking) based on java, tomcat5, mysql4.1 from old server fedora 4 to new server running Centos 5. So, I don?t

Hi, In the process of looking at whether it's reasonable to make ARM use MCJIT by default, I was trying to check that x86-64 uses MCJIT by default (ie, lli doesn't need an explicit -use-mcjit to be passed). However, after instrumenting the constructors for both JIT and MCJIT, either lli doesn't default to using MCJIT on x86-64 or The construction/non-construction of a JIT/MCJIT object

Out of curiosity, I'm replacing the JIT with MCJIT on my compiler. As all "external" functions are provided by the language's FFI mechanism, it does MyExecutionEngine->DisableSymbolSearching(); MyExecutionEngine->InstallLazyFunctionCreator(&MyLazyFunctionCreator); which works fine with the JIT. However, MCJIT insists on resolving unknown symbols by searching them

Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> writes: > When writing a JIT compiler using LLVM, as I understand it, you can use two > alternative APIs, MCJIT and Orc. The latter offers lazy compilation. Would > it be accurate to say that if you want eager compilation - always compile > an entire module upfront - you should use MCJIT? +lang. My understanding is that

When writing a JIT compiler using LLVM, as I understand it, you can use two alternative APIs, MCJIT and Orc. The latter offers lazy compilation. Would it be accurate to say that if you want eager compilation - always compile an entire module upfront - you should use MCJIT? -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Wed, Sep 19, 2012 at 12:42:18AM +0000, Kaylor, Andrew wrote: > It seems to me that MCJIT would be a nice default on the platforms that support it. On the other hand, I don't like the idea of the default behavior being platform dependent. > > Perhaps the biggest obstacle to changing the default is that it would have complicated implications for the automated tests. The testing of

Óscar Fuentes <ofv at wanadoo.es> writes: > Out of curiosity, I'm replacing the JIT with MCJIT on my compiler. As > all "external" functions are provided by the language's FFI mechanism, > it does > > MyExecutionEngine->DisableSymbolSearching(); > MyExecutionEngine->InstallLazyFunctionCreator(&MyLazyFunctionCreator); > > which works fine

On Wed, Sep 19, 2012 at 12:42:18AM +0000, Kaylor, Andrew wrote: > It seems to me that MCJIT would be a nice default on the platforms that support it. On the other hand, I don't like the idea of the default behavior being platform dependent. > > Perhaps the biggest obstacle to changing the default is that it would have complicated implications for the automated tests. The testing of

Right, but is there any known use case where Orc's flexibility allows something to be done that couldn't be with MCJIT, apart from lazy compilation? On Wed, Mar 30, 2016 at 12:19 AM, Justin Bogner <mail at justinbogner.com> wrote: > Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> writes: > > When writing a JIT compiler using LLVM, as I understand it, you

A need has arisen to generate code using MCJIT but not in the target process instead in a different process (and possibly even different machine though not in the scope). Reading through the tutorials and MCJIT design document, it seems like this is possible or was kept in mind during design of MCJIT. How do I achieve this? Are there examples? Dave -------------- next part -------------- An

Greetings, I have a simple C++ EDSL working using the JIT execution engine. When I upgraded to LLVM 3.2 (effortless upgrade, awesome stuff!) I thought I would try taking the MCJIT for a spin after having read that the JIT is considered to be "legacy". So the changes I made to my code were: + #include <llvm/ExecutionEngine/MCJIT.h> - #include <llvm/ExecutionEngine/JIT.h> +

Am 04.06.2013 16:05, schrieb David Tweed: > | I am curious about JMM->invalidInstructionCache(), which I found in > | lli.cpp implementation. lli.cpp contains also call finalizeObject(), I > | just overlooked it. lli.cpp calls finalizeObject(), which calls > | applyPermissions, which in turn calls invalidateInstructionCache. So why > | lli.cpp does call