similar to: [LLVMdev] fix-point support

Hi, is there any work ongoing in the area of fix-point support for LLVM? If not, what would be required to implement it? /Jonas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101022/93cc14b4/attachment.html>

<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

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 >

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

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

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

Hi, As my target supports signed / unsigned interpretation of operands, I was a bit startled to find that the LLVM I/R does not express this info of the integer operands. I want to create an eg unsigned mul if the operands are unsigned, using an intrinsic. I find that with -g, metadata is generated which seems to convey this information. Is it safe to base this type of transformation on the

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

> 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. > > > > I think you should write a rationale explaining why you want to > > introduce new types etc rather than using the

On Oct 7, 2011, at 8:14 AM, Jonas Paulsson wrote: > Hi, > > I think I've found a bug in this method. > > I ran it on an MI which already had two implicit-use operands, and which defined a register with a subregindex, ie reg::lo16. > > For the def-operand, with a subregindex, an implicit-use operand was added with this code: > >

Hi, 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. /Jonas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110311/c2179915/attachment.html>

Hi, I think I've found a bug in this method. I ran it on an MI which already had two implicit-use operands, and which defined a register with a subregindex, ie reg::lo16. For the def-operand, with a subregindex, an implicit-use operand was added with this code: VirtUseOps.insert(VirtUseOps.begin(), MI.getNumOperands()); MI.addOperand(MachineOperand::CreateReg(VirtReg,

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

On Apr 17, 2013, at 2:33 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Jonas Paulsson" <jonas.paulsson at ericsson.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Wednesday, April 17, 2013 12:22:49 AM >> Subject: RE: [LLVMdev] alias analysis in backend

----- Original Message ----- > From: "Andrew Trick" <atrick at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Jonas Paulsson" <jonas.paulsson at ericsson.com>, llvmdev at cs.uiuc.edu > Sent: Thursday, April 18, 2013 2:33:52 AM > Subject: Re: [LLVMdev] alias analysis in backend > > > On Apr 17, 2013, at 2:33 AM,

Hi Hal, Thanks. How about a symbol with two different immediate offsets - the Value* would be the same, right? I don't see how AliasAnalysis::Location would handle this... And BasicAliasAnalysis does if (V1 == V2) return MustAlias; , so I'm not sure how this would be done .. ? /Jonas > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent:

Hello all, I've been wondering why Clang doesn't generate non-temporal stores when compiling the STREAM benchmark [1] and therefore doesn't yield optimal results. It turned out that the Loop Vectorizer correctly vectorizes the arithmetic operations and also merges the loads and stores into vector operations. However it doesn't add the '!nontemporal' metadata which would