similar to: [LLVMdev] JIT support for new architectures

Hi Frank, > We are looking at a variety of target architectures. Ultimately we aim to run on BG/Q and Intel Xeon Phi (native). However, running on those architectures with the LLVM technology is planned in some future. As a first step we would target vanilla x86 with SSE/AVX 128/256 as a proof-of-concept. Great! It should be easy to support these targets. When you said wide-vectors I assumed

Dear LLVM contributors, I am Naoki Shibata, an associate professor at Nara Institute of Science and Technology. I and Hal Finkel would like to jointly propose to add my vectorized math library to LLVM. The library has been available as public domain software for years, I am going to double-license the library if necessary. ******** Below is a proposal to add my vectorized math library,

Hi, everyone, I would like to know if anyone is still making use of the support in the PowerPC backend for the IBM BG/Q supercomputer, including the support for its QPX vector instruction set. If you are, please reply. I'm not aware of any still-running BG/Q machines, and if no one is making use of this functionality, I propose that we remove it. Thanks again, Hal Hal Finkel Lead, Compiler

It's not much. (gdb) bt #0 0x00007ffff7f6506b in ?? () #1 0x000000000045d01a in main () at main.cc:165 Line 165 is the call to the function that was compiled by the JIT'er. Meaning that JIT'ing the function went well, but the code or the pointer are somehow corrupt. There is no particular reason why I am working with the legacy interface. Would you recommend to use the MCJIT

I am having an issue with MCJIT on the ppc64 machine architecture. The symptom is that for a particular IR function the target machine won't emit neither an object nor an assembly file and subsequent calling the pointer to function results in a segfault. My application generates on the fly several functions with the builder and executes them with the MCJIT engine. I came across this

Do you have a stack trace of the segfault? We have two different code emitters for X86 in LLVM. The one used by the normal compiler and MCJIT and the other used by the legacy JIT. All of the test cases for AVX support go through the first one so it gets the most attention. We try to keep the legacy JIT in sync with it, but have a history of failing at that. The stack trace of the segfault may

Hi Alex, loading the symbols explicitly helped. With this the build process doesn't need any additional linker flags. Very nice. Thanks, Frank On 06/28/2018 04:38 PM, Alex Denisov wrote: > Hi Frank, > > If I am not mistaken it doesn't look in the whole process space by default. > Please, try loading all the symbols explicitly: > >

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

The MachO handling isn’t always straightforward in that it has a lot of bit fields to handle while it’s also trying to accommodate the format abstractions baked into the interfaces. The actual relocation type gets extracted in the RuntimeDyldMachO::resolveRelocation function (RuntimeDyldMachO.cpp:32) before it is passed on to the architecture-specific handlers. So the mask you mentioned is

Hi, I'm migrating my code (running on mac) from using JIT to MCJIT. My code generates in memory, mostly using the llvm-c api, and then runs the generated code. When I try to use MCJIT I encounter a problem with relocations of external symbols – functions compiled statically beforehand with gcc. I get the following error: Invalid relocation type! UNREACHABLE executed at

I am upgrading our JIT application to use LLVM 6.0.0, and with this transition I am making the move to use the new MCJIT facility. A problem I am encountering is that the math functions from libm are not resolved/found. I am using the lambda resolver from the KaleidoscopeJIT class which first searches the present modules and, if that is unsuccessful, continues the search in the whole process

Hi, for my application (uses Builder and MCJIT) I am making the transition LLVM 6.0 -> 8.0. It runs fine for self-contained functions, but whenever a jit-ed function contains calls to the math library (e.g. @cosf) it seems to have problems getting the address after successfully finding the symbol: Failure value returned from cantFail wrapped call UNREACHABLE executed at

Hi Gaël, I'm glad to hear that MCJIT looks promising to you. > I understand the point. Probably that providing a small example that describes how using > advanced features of MCJIT could help. If I can manage to make MCJIT works with VMKit, > I'll be happy to send you an example of lazy compilation that highlight some of the features > of MCJIT. I'd love to have a

Thank you for the help. The relocation type value is anded with 0xffffffffL. (RuntimeDyldMachO.cpp:214) Maybe this mask should be different? Anyway, it seems like this relocation isn't implemented. (RuntimeDyldMachO.cpp:104) From: Jiong Wang <jiwang at tilera.com<mailto:jiwang at tilera.com>> Date: Tue, 9 Apr 2013 09:42:03 -0400 To: Eran Weiss <eran.weiss at

? 2013/4/9 21:08, Weiss, Eran ??: > Hi, > > I'm migrating my code (running on mac) from using JIT to MCJIT. My > code generates in memory, mostly using the llvm-c api, and then runs > the generated code. > When I try to use MCJIT I encounter a problem with relocations of > external symbols -- functions compiled statically beforehand with gcc. > > I get the

Thanks, Eran. I’m not sure how soon I’ll have a solution for you, but it’s on my to-do list now. I’ll also create a bugzilla record for this problem. -Andy From: Weiss, Eran [mailto:Eran.Weiss at emc.com] Sent: Thursday, April 11, 2013 12:40 AM To: Kaylor, Andrew Cc: llvmdev at cs.uiuc.edu; Jim Grosbach; Jiong Wang Subject: Re: [LLVMdev] Migration from JIT to MCJIT Andrew, I've attached

Eran, Is there any chance you could boil this down to a small reproducer? I’ve got a mid-to-long-term goal of getting rid of the ugliness in LLDB that Jim mentioned, and fixing your problem would be a good first step. Thanks, Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent: Wednesday, April 10, 2013 4:19 PM To: Kaylor, Andrew; Jiong Wang Cc: Weiss, Eran; llvmdev at cs.uiuc.edu

Hi Gaël, Thank you for the detailed explanation. It's very helpful. All of the things you describe could be done within MCJIT, but I'm not sure that's where they belong. We had a discussion about lazy function compilation at the LLVM Developers Meeting last week and the consensus among those present was that it would be better to leave this sort of lazy compilation to the MCJIT

Existing clients (LLDB) deal with externals by resolving them to constant function pointers that are referenced in the IR. That’s obviously ugly as hell, but it gets things done. The old JIT was able to simplify things because it assumed the JITed code was running in the same process as the JIT compiler. The MCJIT doesn’t assume that, so it has to handle more possibilities. For example, that the

Hi Andy, Thanks for the answer. I'm currently reading the internal code of MCJIT and it's really a great work (I was only using the ExecutionEngine interface for the moment). So, I agree, all what I need is already in the code (see below) :) 2013/11/14 Kaylor, Andrew <andrew.kaylor at intel.com>: > Hi Gaël, > > Thank you for the detailed explanation. It's very