similar to: [LLVMdev] Runtime optimization of C++ code with virtual functions

> On Wed, 20 Jun 2007, Maurizio Vitale wrote: >>>> Is there any possible method using LLVM that would help in this >>>> case? >>> >>> LLVM won't help in this case. >> >> Is that so or it means that LLVM wouldn't have a prebuilt solution? > > It means that LLVM doesn't have any trivial builtin solution. > >>

On Jun 19, 2007, at 1:43 AM, Chris Lattner wrote: > On Sat, 16 Jun 2007, [ISO-8859-1] Stéphane Letz wrote: >> At runtime after a graph is created, one could imagine optimizing by >> resolving call to "virtual Compute" and possibly get a more >> efficient Compute method for the entire graph, so that we could >> write: >> >> DSP* graph = new

On Sat, 16 Jun 2007, [ISO-8859-1] St�phane Letz wrote: > At runtime after a graph is created, one could imagine optimizing by > resolving call to "virtual Compute" and possibly get a more > efficient Compute method for the entire graph, so that we could write: > > DSP* graph = new PAR_DSP(new SEQ_DDSP(new CONCRETE_DSP(), new > CONCRETE_DSP()), new CONCRETE_DSP()); >

Let's say we have the following scheme using C++ and virtual functions: class DSP { public: DSP() {} virtual ~DSP() {} virtual int Compute(int count, float** in, float** out) = 0; }; class CONCRETE_DSP : public DSP { public: CONCRETE_DSP():fValue() {} virtual ~CONCRETE_DSP() {} virtual int Compute(int count, float** in, float** out) { DoSomeProcess(); } }; class

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

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

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

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

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

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

> > Message: 3 > Date: Tue, 12 Jun 2007 10:42:50 -0700 (PDT) > From: Chris Lattner <sabre at nondot.org> > Subject: Re: [LLVMdev] Partial evaluation and LLVM > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Message-ID: <Pine.LNX.4.62.0706121039530.30413 at nondot.org> > Content-Type: text/plain; charset="iso-8859-1" > > On Tue,

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

I understand you to mean that you have isolated the actual execution time as your point of comparison, as opposed to including runtime loading and so on. Is this correct? One thing that changed between 3.1 and 3.3 is that MCJIT no longer compiles the module during the engine creation process but instead waits until either a function pointer is requested or finalizeObject is called. I would

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