similar to: ABI for i256 in MCJIT

Hi LLVM, This is my idea I had some time ago, when I realized that LLVM did not support legalization of some arithmetic instructions like mul i256. I have implemented very simple and limited version of that in my project. Is it something LLVM users would appreciate? 1. The pass transforms IR and is meant to be run before CodeGen (after IR optimizations). 2. The pass replaces

Hi LLVM, 1. Can mul and/or div support be added for big integer types like i256? 2. What are the limits? 3. If yes, how should it be done? I have experience only with X86 target and know that mul i128 works and div i128 is lowered to function call from compile-rt like library (what works only if you link with such library). Can that support be extended? - Paweł -------------- next part

Thanks! Currently using MCJIT. But migration to ORC is on my TODO list. - Paweł On Thu, May 12, 2016 at 8:30 PM Lang Hames <lhames at gmail.com> wrote: > Hi Pawel, > > Option (1) and (3) are very similar, but using custom resolution (option > 3) guarantees that JIT'd code can't accidentally end up depending on > functions in your JIT that you didn't mean to

Hello everyone, I need some advises about (re)using ExecutionEngine with MCJIT as a driver. I'm developing a service that receives a piece of high-level code, compiles it into LLVM IR function "main" and uses MCJIT to execute the function. It can happen that the same piece of code is sent to the service many times. I would like to cache the results (keep generated machine code

On Aug 17, 2012, at 2:50 AM, Paweł Bylica <pawel.bylica at ibs.org.pl> wrote: > On Fri, Aug 17, 2012 at 12:16 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Hi Paweł, > > > > Thanks for continuing this discussion. > > > > I like the simplicity of your suggestion. My only concern involves the ambiguity of what is meant by “environment”.

ping From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew Sent: Tuesday, August 28, 2012 11:10 AM To: Jim Grosbach; Pawel Bylica; Chris Lattner Cc: llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu) Subject: Re: [LLVMdev] RFC: MCJIT enhancements Has anything more happened with this? -Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent:

Has anything more happened with this? -Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent: Friday, August 17, 2012 7:51 AM To: Paweł Bylica; Chris Lattner Cc: llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu); Kaylor, Andrew Subject: Re: [LLVMdev] RFC: MCJIT enhancements On Aug 17, 2012, at 2:50 AM, Paweł Bylica <pawel.bylica at ibs.org.pl<mailto:pawel.bylica at ibs.org.pl>>

Hi everyone, I was happily using MCJIT for over a year until yesterday when I created a function call with an argument of a struct type. That caused a crash in SelectionDAG around DataLayout::getAlignment(). I remember the noise about the DataLayout started being mandatory. But I cannot find precise information. Should I set the DataLayout in every Module created? Where can I get the

Hi, I think ExecutionEngine as a common interface for both Interpreter and MCJIT is almost useless in the current form. There are separated methods in ExecutionEngine for similar or the same features provided by Interpreter and MCJIT, i.e. to get a pointer to function you should call getPointerToFunction() for Interpreter or getFunctionAddress() for MCJIT. Personally, I'm using MCJIT and

Chris, are you OK with the below changes to the Triple? -Jim On Sep 4, 2012, at 5:21 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > ping > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew > Sent: Tuesday, August 28, 2012 11:10 AM > To: Jim Grosbach; Pawel Bylica; Chris Lattner > Cc: llvmdev

On Sep 4, 2012, at 5:23 PM, Jim Grosbach <grosbach at apple.com> wrote: > Chris, are you OK with the below changes to the Triple? If at all possible, I'd like to keep the triple changes separate (separate patch series and separate discussion) from the other MCJIT changes. How dependent are the MCJIT improvements on the Triple changes? As you've noticed, Triple is not a

Hi LLVM, Lang. I'm looking for a advice here. And I truly understand very little what the relocations are and how they work. The problem I want to solve is the case where a jitted code has to call back the host application to query additional data. I can think of 3 possible solutions: 1. Use built-in relocation resolver (in default memory manager?) and allow the JIT to find the

On Wed, Jul 25, 2012 at 12:24 AM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > > -------------------------------**** > > ELF Support on Windows**** > > -------------------------------**** > > **** > > There are various reasons that it would be nice to be able to support > generation of ELF objects on Windows through the MCJIT interface, one of >

On Tue, Jul 21, 2015 at 5:55 PM Justin Bogner <mail at justinbogner.com> wrote: > Paweł Bylica <chfast at gmail.com> writes: > > I can confirm that the issue has been caused by NDEBUG flag. > > > > On Mon, Jul 13, 2015 at 6:29 PM Reid Kleckner <rnk at google.com> wrote: > > > > The layout of AssertingVH has depended on NDEBUG since 2009,

On Tue, Jul 21, 2015 at 6:30 PM Justin Bogner <mail at justinbogner.com> wrote: > Paweł Bylica <chfast at gmail.com> writes: > > On Tue, Jul 21, 2015 at 5:55 PM Justin Bogner <mail at justinbogner.com> > wrote: > > > > Paweł Bylica <chfast at gmail.com> writes: > > > I can confirm that the issue has been caused by NDEBUG flag. >

Another question: Lang, when do you think it'll be ok to move it to the C Bindings? On Fri, Mar 13, 2015 at 6:39 PM, Lang Hames <lhames at gmail.com> wrote: > Hi Pawel, > > I agree. ExecutionEngine, in its current form, is unhelpful. I'd be in > favor of cutting the common interface back to something like: > > class ExecutionEngine { > public: > virtual

Hi Paweł, Thanks for continuing this discussion. I like the simplicity of your suggestion. My only concern involves the ambiguity of what is meant by “environment”. Presently there are functions in the llvm::Triple class to access the environment as an enumeration of a fixed set of values. It seems that some non-enumerated values are already in use, but introducing possible combinations of

Thu Jul 12 03:42:12 CDT 2012, Verena Beckham verena at codeplay.com : > I would not say it is trivial, having done it myself. > > MCJIT also doesn't support multiple modules, and it does not do JITing > on demand, instead, it does all of it at the same time in the > constructor (unless that is what you call "not lazy"). > So depending on how you've written your

Hello all I have a very simple handwritten .ll file that can be translated to native assembly on x86_64 when I use i128. But if I use i256 I get an error. see the file and the first line of the error below. Any help is appreciated! I played a little bit with target datalayout but it didn't help. Best Ehsan Input File: target datalayout =

On Fri, Aug 17, 2012 at 12:16 AM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Hi Paweł,**** > > ** ** > > Thanks for continuing this discussion.**** > > ** ** > > I like the simplicity of your suggestion. My only concern involves the > ambiguity of what is meant by “environment”. Presently there are functions > in the llvm::Triple class to access