similar to: [LLVMdev] Strategy to compile for LLVM IR

> > Message: 3 > Date: Fri, 15 Jun 2007 12:24:52 -0700 (PDT) > From: Chris Lattner <sabre at nondot.org> > Subject: Re: [LLVMdev] Strategy to compile for LLVM IR > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Message-ID: <Pine.LNX.4.62.0706151218030.7416 at nondot.org> > Content-Type: text/plain; charset="x-unknown" > > On

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 > > On May 28, 2010, at 12:13 PM, Stéphane Letz wrote: We are actually testing LLVM for the Faust language

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, 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

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

Hello, I am using the Faust language which leverages LLVM's MCJIT for code generation (http://faust.grame.fr/). There are some problems[1] when generating code and executing it afterwards on Windows with a MSVC "host" (that is, LLVM itself and the software it is used in are built with MSVC). It works fine when building LLVM / Faust with Mingw. On MSVC the code is generated with

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 On May 28, 2010, at 12:13 PM, Stéphane Letz wrote: > Hi, > > We are experimenting directly generating vectorized LLVM IR (using <8 x float> kind of types), then compiling the code

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 1:18 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > 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

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

Hi, and thanks for the feedback. >My own gut feeling on this is that you'd be better off figuring out >how to do this in the context of Faust, which already does a important >subset of what you are describing, though notably without (I think) >the LLVM part. Surely a contribution to the discussion by the Faust people would be welcome; and even more than to the discussion :->.

Hey Guys, I'm working on a project in Android related to System-level Audio DSP Effects for Tuning Android Audio. I want to leverage Faust ( https://faust.grame.fr/) to allow users to program their own filters. Faust provides a libfaust implementation which includes a JIT Compiler which leverages LLVM and seems to be the best path for me to use. Unfortunately I'm having problems

On Mon, Dec 6, 2010 at 6:10 AM, Maurizio De Cecco <jmax at dececco.name> wrote: > I have been looking for a while to  LLVM as a possible technology to build a > DSP execution engine, providing the runtime flexibility needed by real-time > interactive DSP applications (like patcher languages), or by plug-in based > processors, and in the same moment > the powerful link time

> > Message: 4 > Date: Fri, 15 Jun 2007 12:25:30 -0700 (PDT) > From: Chris Lattner <sabre at nondot.org> > Subject: Re: [LLVMdev] Strategy to compile for LLVM IR > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Message-ID: <Pine.LNX.4.62.0706151224570.7416 at nondot.org> > Content-Type: text/plain; charset="x-unknown" > > On

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

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, >>>>

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);

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

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

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