similar to: [LLVMdev] Mul & div support for wider-than-legal types

On Sun, Mar 22, 2015 at 5:57 AM Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Fri, Mar 20, 2015 at 08:06:11PM -0700, Tim Northover wrote: > > > mul can be inlined easily if necessary for arbitrary sizes, but div is > very expensive. > > > > Shall I file a bug for "implement FFT in LLVM"? > > I didn't say it is the most efficient

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 everyone! Here, I have a question and am curious about i128. I want to know how the LLVM handle i128, because many compiler backend doesn't support i128 directly. So I am very curious and want to how the llvm handle this situation? Besides i128, such as i256, i512, even i24? Thanks. Best Regards Wu Zhao -------------- next part -------------- An HTML attachment was scrubbed...

Hi, I have a small JIT project based on MCJIT. The generated LLVM IR code uses the i256 type. Also, the jitted code has to call back the host application from time to time. E.g. it calls a function i256 @callback(i256). 1. Can the callback function be implemented on the host application side (C/C++) to match the ABI used for the call by MCJIT? Or maybe the i256 has be to be casted to

First off, most of my information about the integer representation in LLVM is from http://llvm.org/docs/LangRef.html#t_integer and I could use some things cleared up. First, I guess that smaller integer sizes, say, i1 (boolean) are stuffed into a full word size for the cpu it is compiled on (so 8bits, or 32 bits or whatever). What if someone made an i4 and compiled it on 32/64 bit windows/nix/bsd

Hi, I am currently working on an opencl project based on LLVM, the target device is 32bit. I met a problem that some llvm passes like GVN SROA will generate some IR operating on wide integer types like i128 or i512. But the device does not support such kind of data type. Is there any idea on how to lower this kind of IR to only operate on i32 or vector of i32? Or is there any existing code handle

Hi everyone. After lurking for a while, this is my first post to the list. I am working with some graduate students on the general topic of compiler support for SIMD programming and specific projects related to LLVM and my own Parabix technology (parabix.costar.sfu.ca). Right now we have a few course projects on the go and already a question arising out of one of them (SSE2 Hoisting).

> mul can be inlined easily if necessary for arbitrary sizes, but div is very expensive. Shall I file a bug for "implement FFT in LLVM"? Tim.

----- Original Message ----- > From: "Paweł Bylica" <chfast at gmail.com> > To: "LLVMdev" <llvmdev at cs.uiuc.edu> > Sent: Friday, May 22, 2015 8:45:11 AM > Subject: Re: [LLVMdev] Problems with instruction scheduling > > > > Any comments? Not in particular, but I think we're pretty close to applying a rewrite by Jonas Paulsson

----- Original Message ----- > From: "Paweł Bylica" <chfast at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVMdev" <llvmdev at cs.uiuc.edu>, "Jonas Paulsson" <jonas.paulsson at ericsson.com> > Sent: Friday, May 22, 2015 9:19:14 AM > Subject: Re: [LLVMdev] Problems with instruction scheduling > >

Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> writes: > On Mon, Jun 20, 2016 at 05:05:18PM +0000, Paweł Bylica via llvm-dev wrote: >> On Sun, Jun 19, 2016, 17:57 Joerg Sonnenberger <joerg at bec.de> wrote: >> >> > On Sun, Jun 19, 2016 at 03:24:22PM +0000, Paweł Bylica via llvm-dev wrote: >> > > Hi LLVM, >> > > >>

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”.

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

On Sun, Jun 19, 2016, 17:57 Joerg Sonnenberger <joerg at bec.de> wrote: > On Sun, Jun 19, 2016 at 03:24:22PM +0000, Paweł Bylica via llvm-dev wrote: > > Hi LLVM, > > > > I want to complain a bit about the quality of the code included in the > > public LLVM headers. For projects that depend on LLVM is really hard to > > just include LLVM headers not to

Hi, I'm interested in any information about implementations of switch instruction and its runtime cost. If it's very target dependent, I'm mostly care about X86. Pointing some LLVM code is also good. - Paweł -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141027/285f02e5/attachment.html>

Hi, Following is excerpted from http://llvm.org/releases/3.1/docs/LangRef.html#int_ctpop. How come the return type needs to be consistent with parameter type? i64/i128 seems to be overkill, and i8, i16 are inconvenient. ----------------------------------- declare i8 @llvm.ctpop.i8(i8 <src>) declare i16 @llvm.ctpop.i16(i16 <src>) declare i32 @llvm.ctpop.i32(i32

----- Original Message ----- > From: "Pete Cooper" <peter_cooper at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVMdev" <llvmdev at cs.uiuc.edu>, "Paweł Bylica" <chfast at gmail.com> > Sent: Wednesday, July 1, 2015 6:42:41 PM > Subject: Re: [LLVMdev] extractelement causes memory access violation - what 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

----- Original Message ----- > From: "Pete Cooper" <peter_cooper at apple.com> > To: "Paweł Bylica" <chfast at gmail.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "LLVMdev" <llvmdev at cs.uiuc.edu> > Sent: Wednesday, July 1, 2015 12:08:37 PM > Subject: Re: [LLVMdev] extractelement causes memory access violation - what

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,