similar to: [LLVMdev] [cfe-dev] Clang, #include <math.h>

Hi, thanks a lot for the answer. By mem, I meant optimizations that involves load/store intrinsics, eg llvm.fixPload(). What would the consequences of this be? I ask then, is there any interest at all in the LLVM community for fixed point support in the future? Are there even any local successful projects that you know of? Did you mean that fixed point support in terms of intrinsics and code

Hi, all right, no fixed point type in LLVM :-( May I ask then, what could one expect from various optimizations when using intrinsics to support the fixed point type? LTO, Value optimizations, mem ?? Are you saying it is feasible to add intrinsics and some extra optimizers for these, then? Best regards, Jonas > Subject: Re: [LLVMdev] fixed point types > From: clattner at apple.com >

I have a few pass managers, but only one of them has been initialized with addPassesToEmitCode, how do I find how many passes are added to a function pass manager ? Thank you, Xin On Fri, May 20, 2011 at 1:00 PM, <llvmdev-request at cs.uiuc.edu> wrote: > Send LLVMdev mailing list submissions to > llvmdev at cs.uiuc.edu > > To subscribe or unsubscribe via the World Wide

<retitling to be useful> LLVM shouldn't have a fixed point type class. You should just use standard integer types. Supporting fixed point and saturation should by done by adding new operations to llvm IR. If you're interested in this, I'd suggest starting by implementing these as intrinsics. If it makes sense over time we can change them to primitive instructions if there is

Jonas Paulsson <jnspaulsson at hotmail.com> writes: > is it possible to reduce link time by excluding unused target backends? > > I would like to type > > tools/llc make -target=... , and just build it for one backend. If you build with configure && make, use the configure option --enable-targets. If you build with cmake && make, pass

> On Friday, November 26, 2010 4:32 PM > Jonas Paulsson <jnspaulsson at hotmail.com> wrote: > > Well, the reason DSP compilers would benefit from the new type, is that > fixed point numbers must not be optimized > as integers - eg if two saturated fixed point constants would overflow in > an addition operation, the result should as > well be saturated. Doing this in

On Tue, Nov 30, 2010 at 2:48 PM, Jonas Paulsson <jnspaulsson at hotmail.com> wrote: > all right, no fixed point type in LLVM :-( > > May I ask then, what could one expect from various optimizations when using > intrinsics to support the fixed point type? LTO, Value optimizations, mem ?? You'd have to implement explicit support for the new intrinsics in various places. For

On Tue, Nov 30, 2010 at 05:48, Jonas Paulsson <jnspaulsson at hotmail.com> wrote: > > May I ask then, what could one expect from various optimizations when using > intrinsics to support the fixed point type? LTO, Value optimizations, mem ?? > Can you not just lower your fixed-point operations to widen, perform normal integer operation, shift and truncate? With LLVM's

I see, thanks. I used to work with GCC, which has an SSA-property verification run after each pass. It is surprising to find that LLVM does not check this! Jonas > Subject: Re: [LLVMdev] subregisters, def-kill > From: stoklund at 2pi.dk > Date: Thu, 19 May 2011 15:39:40 -0700 > CC: llvmdev at cs.uiuc.edu > To: jnspaulsson at hotmail.com > > > On May 19, 2011, at 7:47

Yes, I'm saying that the implicit-def operand that was added in this case ended up as #4, out of 6, when the operands list was reallocated in addOperand(). If addOperand was rewritten, I think it's best not to add my fix for ProcessUses(), as I wrote earlier. Jonas Subject: Re: [LLVMdev] VirtRegRewriter.cpp: LocalRewriter::ProcessUses() From: stoklund at 2pi.dk Date: Wed, 12 Oct 2011

You probably meant to send this to LLVMdev as well. Begin forwarded message: Date: Mon, 29 Nov 2010 08:26:03 +0100 From: Jonas Paulsson <jnspaulsson at hotmail.com> To: <edwintorok at gmail.com> Subject: RE: [LLVMdev] LLVMdev Digest, Vol 77, Issue 41 Yes, the new type is simply a static object managed by Type and LLVMContext. This is only referred to by Values of fixed point type.

On Wed, Dec 1, 2010 at 8:11 AM, me22 <me22.ca at gmail.com> wrote: > On Tue, Nov 30, 2010 at 05:48, Jonas Paulsson <jnspaulsson at hotmail.com> wrote: >> May I ask then, what could one expect from various optimizations when using >> intrinsics to support the fixed point type? LTO, Value optimizations, mem ?? >> > > Can you not just lower your fixed-point

Hi, I understand the idea behind compare_numeric() is to compare strings containing digits in a special way: Do a normal string-compare up to the point where both string elemnts are numerical. Find then an outcome based on the number of consecutive digits in the strings while disregarding the value of the digits, eg a12b < a123. I guess then this order should hold: a12 == a22 < a1b, for

When I compile the following program (for ARM): for(i=0;i<n2;i+=n3) { s+=a[i]; } , with GCC, I get the following loop body, with a post-modify load: .L4: add r1, r1, r3 ldr r4, [ip], r6 rsb r5, r3, r1 cmp r2, r5 add r0, r0, r4 bgt .L4 With LLVM, however, I get: .LBB0_3: @

On Fri, 26 Nov 2010 16:32:42 +0100 Jonas Paulsson <jnspaulsson at hotmail.com> wrote: > > > > > On Thu, 25 Nov 2010 11:06:48 +0100 > > Duncan Sands <baldrick at free.fr> wrote: > > > > > Hi Jonas, > > > > > > > I am investigating the possibilities of incorporating fixed > > > > point support into the LLVM I/R.

If I write %reg16506<def> = INSERT_SUBREG %reg16506, %reg16445, hi16; #1 %reg16506<def> = INSERT_SUBREG %reg16506, %reg16468, lo16; #2 store %reg16506 #3 it will not coalesce, as LiveVariables: on #2: %16506 gets #2 as a kill #3: %16506 gets #3 as an additional kill LiveIntervalAnalysis:

Hi, Thanks for your help. It's true. I had to point files to the arm files. i have modified my command line by adding --with-ogg-libraries=/armbuild/lib/ . Here is the ogg.h file compiled for arm. But now i have an other error : source='speexdec.c' object='speexdec.o' libtool=no \ depfile='.deps/speexdec.Po' tmpdepfile='.deps/speexdec.TPo' \

Hi, thank you for your explanations. In order to get a pre-RA scheduling, I would need something like: - LiveVars - PhiElim - TwoAddr - LiveIntervals - Coalescing - Scheduler (new) - SlotIndexing - LiveIntervals2 (new) - RegAllocMy qeustion then is, is it really so difficult to create the live intervals information, with modifications to the original algorithm, or even from scratch?

What about the coalescing - How could you schedule if you did not know which COPY's would remain/eliminated? This is why I would like to do scheduling after SimpleRegCoalesc. Jonas > Date: Wed, 25 May 2011 12:11:18 +0800 > Subject: Re: [LLVMdev] Need advice on writing scheduling pass > From: etherzhhb at gmail.com > To: stoklund at 2pi.dk > CC: jnspaulsson at hotmail.com;

This is cropping up more than I expected. Apparently, many distributions are still shipping their latest versions with the broken glibcs... Recently I decided that a specific glibc bug (that causes mangled audio or crashes) that I found nearly a year ago (and has been fixed for as long) had probably become scarce enough to risk removing the '-D__NO_MATH_INLINES' define from the build.