similar to: [LLVMdev] LLVMdev Digest, Vol 77, Issue 41

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] LLVMdev Digest, Vol 77, Issue 41"

2010 Nov 29
2
[LLVMdev] Fw: LLVMdev Digest, Vol 77, Issue 41
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.
2010 Nov 26
0
[LLVMdev] LLVMdev Digest, Vol 77, Issue 41
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.
2010 Nov 29
2
[LLVMdev] fixed point types
<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
2010 Nov 27
0
[LLVMdev] LLVMdev Digest, Vol 77, Issue 41
> 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
2010 Nov 30
0
[LLVMdev] fixed point types
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 >
2010 Dec 01
2
[LLVMdev] fixed point types
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
2010 Nov 30
2
[LLVMdev] fixed point types
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
2011 Mar 11
2
[LLVMdev] make
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>
2011 Mar 11
0
[LLVMdev] make
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
2010 Dec 01
0
[LLVMdev] fixed point types
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
2011 May 25
2
[LLVMdev] Need advice on writing scheduling pass
> > I assume you put your VLIW scheduler before the register allocator super-pass? right > > /jakob > >
2011 May 19
3
[LLVMdev] subregisters, def-kill
Hi, I am combining 16-bit registers to a 32 bit register in order to make a wide store, as per below: 732 %reg16506:hi16<def,dead> = COPY %reg16445<kill>; 740 %reg16506:lo16<def> = COPY %reg16468<kill>; 748 %r3<def,dead> = store %reg16506<kill>, %r3, As you can see, LiveVariables has marked the high part dead, even though the super-register is used at
2011 May 19
0
[LLVMdev] subregisters, def-kill
On May 19, 2011, at 7:47 AM, Jonas Paulsson wrote: > Hi, > > I am combining 16-bit registers to a 32 bit register in order to make a wide store, as per below: > > 732 %reg16506:hi16<def,dead> = COPY %reg16445<kill>; > 740 %reg16506:lo16<def> = COPY %reg16468<kill>; > 748 %r3<def,dead> = store %reg16506<kill>, %r3, > > As you can
2011 May 25
0
[LLVMdev] Need advice on writing scheduling pass
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;
2011 Sep 30
3
[LLVMdev] Tablegen: RegisterInfoEmitter.cpp
Hi, I just bumped into a bug in this code. The problem was as follows: I have defined a set of registers with rather similar names including digits. The code section at RegisterInfoEmitter::run(){ ... // Process sub-register sets. runs and fills the RegisterAliases map. then, ... for (unsigned i = 0, e = Regs.size(); i != e; ++i) { RegNo[Regs[i].TheDef] = i; NumAliases +=
2011 Oct 07
3
[LLVMdev] VirtRegRewriter.cpp: LocalRewriter::ProcessUses()
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,
2011 Sep 30
0
[LLVMdev] Tablegen: RegisterInfoEmitter.cpp
On Sep 30, 2011, at 8:29 AM, Jonas Paulsson wrote: > The conclusion is that the StringRef::compare_numeric() is not deterministic Thanks for tracking this down. I believe we have a bug in compare_numeric() causing it to be non-transitive sometimes. It is supposed to provide a total ordering of strings. Can you find the bug? /jakob -------------- next part -------------- An HTML attachment
2011 Oct 12
0
[LLVMdev] VirtRegRewriter.cpp: LocalRewriter::ProcessUses()
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: > >
2011 Apr 13
2
[LLVMdev] signedess of operands
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
2011 Jan 28
3
[LLVMdev] Post-inc combining
Hi, I would like to transform a LLVM function containing a load and an add of the base address inside a loop to a post-incremented load. In DAGCombiner.cpp::CombineToPostIndexedLoadStore(), it says it cannot fold the add for instance if it is a predecessor/successor of the load. I find this odd, as this is exactly what I would like to handle: a simple loop with an address that is inremented in