similar to: [LLVMdev] Generating Floating point constants

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 :

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

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

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

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

Hello Can anyone share a known working config for xen which would transfer a serial interface ( add-on card preferably, mine uses e880-e887 : 0000:03:05.0 / ec00-ec07 : 0000:03:05.0 ) to a DomU ? I've been trying with the stock packages from Centos 5.5 ( fully updated) and also with gitco's 3.4.3 but after 2 days of googling and testing we still fail to access the serial

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

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

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

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, 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 "standard float to LLVM float" conversion? Thanks. Stéphane Letz

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

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