similar to: [LLVMdev] Generating 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...) >>

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...) > > Is there any code available in LLVM  to handle this kind of

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" in our code. In http://llvm.org/docs/LangRef.html it is explained that FP has to follow special

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"

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

On Jun 3, 2010, at 7:05 AMPDT, Stéphane Letz wrote: > Le 3 juin 2010 à 16:00, Martin Guy a écrit : > >> [off list] >> >>> 0.8f get converted in 0x3FE99999A0000000 by LLVM >> >> single precision >> >>> http://babbage.cs.qc.edu/IEEE-754/Decimal.html gives: >>> >>> 0x3FE999999999999A instead and this value cannot be read back

Le 3 juin 2010 à 16:00, Martin Guy a écrit : > [off list] > >> 0.8f get converted in 0x3FE99999A0000000 by LLVM > > single precision > >> http://babbage.cs.qc.edu/IEEE-754/Decimal.html gives: >> >> 0x3FE999999999999A instead and this value cannot be read back by "llc"... > > double precision > > M Well For float 0.8 :

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

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

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

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

Le 15 juin 2010 à 21:14, Chris Lattner a écrit : > > On Jun 15, 2010, at 11:51 AM, Stéphane Letz wrote: > >>> Nope, types are immutable once created. The only thing you can do is "refine" opaque types to other types. There is a section in the programmer's manual on this: >>> http://llvm.org/docs/ProgrammersManual.html#TypeResolve >>>

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 build a type with StructType::get(fModule->getContext(), fDspFields, false); with a fDspFields (std::vector<const llvm::Type*> fDspFields;) that is not yet completely known when we have to build the type. It is possible to add fields in a already build type? Thanks Stéphane Letz

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

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