similar to: [LLVMdev] Partial evaluation and LLVM (2)

> > Message: 2 > Date: Fri, 15 Jun 2007 12:16:32 -0700 (PDT) > From: Chris Lattner <sabre at nondot.org> > Subject: Re: [LLVMdev] Partial evaluation and LLVM (2) > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Message-ID: <Pine.LNX.4.62.0706151213090.7416 at nondot.org> > Content-Type: text/plain; charset="x-unknown" > > On

Hi, Would LLVM be adapted to express and do some kind of function "partial evaluation", like having a function of 2 arguments, and when a value of one of the 2 parameter is known, the function could be specialized to produce as result a more efficient new function that would take one 1 parameter. I was told that the "ReplaceAllUsesWith" operation could be possibly

Le 5 juil. 2013 à 17:23, Arnold Schwaighofer <aschwaighofer at apple.com> a écrit : > > On Jul 5, 2013, at 9:50 AM, Stéphane Letz <letz at grame.fr> wrote: > >> >> Le 5 juil. 2013 à 04:11, Tobias Grosser <tobias at grosser.es> a écrit : >> >>> On 07/04/2013 01:39 PM, Stéphane Letz wrote: >>>> Hi, >>>>

On Sat, May 29, 2010 at 1:23 AM, Stéphane Letz <letz at grame.fr> wrote: >> >> <32 x float> takes up 8 SSE registers; you're likely running into >> issues with register pressure.  Does it work better if you use >> something smaller like <4 x float>? >> >> Besides that, I don't see any obvious issues. >> >> -Eli > >

On Tue, Jul 16, 2013 at 8:16 AM, Stéphane Letz <letz at grame.fr> wrote: > Hi, > > Our DSL emit sub-optimal LLVM IR that we optimize later on (LLVM IR ==> LLVM IR) before dynamically compiling it with the JIT. We would like to simply follow what clang/clang++ does when compiling with -O1/-O2/-O3 options. Our strategy up to now what to look at the opt.cpp code and take part of it

> ------------------------------ > > Message: 4 > Date: Wed, 2 Jun 2010 11:07:39 -0700 > From: Dale Johannesen <dalej at apple.com> > Subject: Re: [LLVMdev] Generating Floating point constants > To: St?phane Letz <letz at free.fr> > Cc: llvmdev at cs.uiuc.edu > Message-ID: <AEC895CC-E887-4329-8743-FA606BD401F6 at apple.com> > Content-Type:

> > <32 x float> takes up 8 SSE registers; you're likely running into > issues with register pressure. Does it work better if you use > something smaller like <4 x float>? > > Besides that, I don't see any obvious issues. > > -Eli You are right yes. The code works faster with <4 x float> types, with still works a bit slower than the scalar

On Thu, Jul 18, 2013 at 9:07 AM, Stéphane Letz <letz at grame.fr> wrote: > Hi, > > Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? > > I tried to play with TargetOptions without any success… > > Here is the kind of code we use to

Hi, We have a compiler for the Faust language (faust.grame.fr) that currently compiles a C++ class which implements a DSP plug-in with several methods. Our strategy to compile LLVM IR instead is the following: - use the current Faust ==> C++ compiler to compile a "empty" plug-in that we use as a template C++ class. - compile this template C++ class using "llvm-g++

On Jul 5, 2013, at 9:50 AM, Stéphane Letz <letz at grame.fr> wrote: > > Le 5 juil. 2013 à 04:11, Tobias Grosser <tobias at grosser.es> a écrit : > >> On 07/04/2013 01:39 PM, Stéphane Letz wrote: >>> Hi, >>> >>> Our DSL can generate C or directly generate LLVM IR. With LLVM 3.3, we can vectorize the C produced code using clang with -O3, or

Le 18 juil. 2013 à 19:07, Eli Friedman <eli.friedman at gmail.com> a écrit : > On Thu, Jul 18, 2013 at 9:07 AM, Stéphane Letz <letz at grame.fr> wrote: >> Hi, >> >> Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? >>

Hi, We have a web page on our "LLVM backend for Faust" project available here: http://www.grame.fr/~letz/faust_llvm.html. Best Regards Stephane Letz

On Jul 5, 2013, at 10:43 AM, Stéphane Letz <letz at grame.fr> wrote > > 1) "entry" block is the first block of the function right? Yes. > > 2) do you mean *all* "alloca" in a function always have to be in the fist entry block? If you want them converted into ssa variables early on, yes.

Le 5 juil. 2013 à 17:48, Arnold Schwaighofer <aschwaighofer at apple.com> a écrit : > > On Jul 5, 2013, at 10:43 AM, Stéphane Letz <letz at grame.fr> wrote >> >> 1) "entry" block is the first block of the function right? > > Yes. OK > >> >> 2) do you mean *all* "alloca" in a function always have to be in the fist entry

Hi, Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? I tried to play with TargetOptions without any success… Here is the kind of code we use to allocate the JIT: EngineBuilder builder(fResult->fModule);

Le 5 juil. 2013 à 04:11, Tobias Grosser <tobias at grosser.es> a écrit : > On 07/04/2013 01:39 PM, Stéphane Letz wrote: >> Hi, >> >> Our DSL can generate C or directly generate LLVM IR. With LLVM 3.3, we can vectorize the C produced code using clang with -O3, or clang with -O1 then opt -O3 -vectorize-loops. But the same program generating LLVM IR version cannot be

Hi, Our DSL emit sub-optimal LLVM IR that we optimize later on (LLVM IR ==> LLVM IR) before dynamically compiling it with the JIT. We would like to simply follow what clang/clang++ does when compiling with -O1/-O2/-O3 options. Our strategy up to now what to look at the opt.cpp code and take part of it in order to implement our optimization code. It appears to be rather difficult to follow

On Sat, May 29, 2010 at 12:42 AM, Stéphane Letz <letz at grame.fr> wrote: > > Le 29 mai 2010 à 01:08, Bill Wendling a écrit : > >> Hi Stéphane, >> >> The SSE support is the LLVM backend is fine. What is the code that's generated? Do you have some short examples of where LLVM doesn't do as well as the equivalent scalar code? >> >> -bw >>

Hi all, I'm rather new to LLVM and intend to dive into partial evaluation with LLVM. I tried to run the example from http://llvm.org/devmtg/2008-08-23/llvm_partial.pdf, which worked after some adaptations, which were necessary, because LLVM evolved since the slides were made. However, I also tried to get the same example running as an optimization pass following the instructions in

Hi, We are experimenting directly generating vectorized LLVM IR (using <8 x float> kind of types), then compiling the code to SSE on a 64 bits machine. Right now the equivalent code in scalar mode sill outperform the SSE one. What is the quality of the SSE support in X86 LLVL backend? Are they any specific things to be aware of to improve the speed? Thanks Stéphane Letz