similar to: [LLVMdev] Advices needed for LLVM IR compilation

Hi, Our compiler currently generates a C++ class. It defines a data structure and emit code to access member of this newly data structure at the same time: access code is compiled when the shape of the complete data structure is not yet known. Can we keep the same scheme when targeting LLVM IR? Can we define a new structured type and compiled acces to fields in the same pass? Or do we

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

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

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

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

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

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

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

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

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

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

Le 2 juin 2010 à 19:48, Dale Johannesen a écrit : > > On Jun 2, 2010, at 3:28 AMPDT, Stéphane Letz wrote: > >> >> Le 2 juin 2010 à 12:21, Eli Friedman a écrit : >> >>> On Wed, Jun 2, 2010 at 2:59 AM, Stéphane Letz <letz at free.fr> wrote: >>>> Hi, >>>> >>>> We need to generate "Floating point constants"

Le 2 juin 2010 à 12:21, Eli Friedman a écrit : > On Wed, Jun 2, 2010 at 2:59 AM, Stéphane Letz <letz at free.fr> wrote: >> Hi, >> >> We need to generate "Floating point constants" in our code. In http://llvm.org/docs/LangRef.html it is explained that FP has to follow special encoding rules to be handled by LLVM later one (hexadecimal coding...) >>