similar to: [LLVMdev] Eliminating dead copies

On 1/18/07, Scott Michel <scottm at rushg.aero.org> wrote: > Is there any way I can detect when this occurs, or is there code > where this detection takes place in the target to which I can > refer? have you implemented InstInfo::isMoveInstr to recognize those? The register allocator uses that to find copies it can remove. Andrew

On 11/27/06, Scott Michel <scottm at rushg.aero.org> wrote: > Anton Korobeynikov wrote: > >>the official cutover. Granted, you might need darcs to pull the current > >>version out of its repo, since it was originally designed with darcs in > >>mind. > > > > I can confirm, that tailor converts LLVM CVS with all history preserved > > to mercurial

I know that Al Stone has compiled llvm-gcc4 successfully and I can report the same. The problem I consistently run into is that llvm-gcc ends up producing native format output; it does not produce bytecode, nor does it invoke gccas or gccld. I'm using the latest svn, and my configure args are: --prefix=/work/scottm/llvm-cfrontend/obj/../i686-pc-linux-gnu \

This is a scheduler assertion. It means a value (virtual register) use is somehow scheduled before its definition. Please run llc in gdb. Call dumpSchedule() to print out the schedule. Also please let me know which node it is processing at the time of the assertion. Evan On Oct 15, 2007, at 11:48 PM, Scott Michel <scottm at aero.org> wrote: > Yup, I've got one remaining bug

Evan: What you requested was in the debug output (sans offending Node), but here it is, outside of the attachment. The offending node is highlighted: SU(0): 0xa908760: ch = EntryToken SU(1): 0xa907600: i32,ch,flag = CopyFromReg 0xa9095d0, 0xa9070e0, 0xa9095d0:1 0xa906e30: ch,flag = CopyToReg 0xa908760, 0xa9070e0, 0xa9071f0 <<--<<--<<--<<--<< Node

2008/12/30 Scott Michel <scottm at aero.org> > Not entirely sure how to categorize this particular problem, but it's > clearly platform test related: "grep -w" appears to operate > differently on the x86_64 linux buildbot versus my local Mac OS > 10.4.11 and Ubuntu x86_64. In the CellSPU's shift_ops.ll test case, > "grep -w shlh" returns the

Sorry, still not enough information. I am guessing it's asserting in getVR() called from EmitNode()? The node is CopyToReg and it's trying to find the virtual register of operand 2? From the schedule, I don't see the definition of the operand. Can you do DAG.viewGraph()? That should gives us a better idea. Evan On Oct 16, 2007, at 9:06 PM, Scott Michel wrote: > Evan: >

Yup, I've got one remaining bug that holding up the CellSPU release. It still has a bunch of warts, but so long as I can get it into shape such that llvm-gcc-4.2 compiles all the way through, then we collectively have something with which to work. I'm getting the following error from llc, the attachments have llc's debug and the .ll files, respectively. Can anyone shed some

On Dec 30, 2008, at 4:55 PM, Misha Brukman wrote: > 2008/12/30 Scott Michel <scottm at aero.org> > Not entirely sure how to categorize this particular problem, but it's > clearly platform test related: "grep -w" appears to operate > differently on the x86_64 linux buildbot versus my local Mac OS > 10.4.11 and Ubuntu x86_64. In the CellSPU's shift_ops.ll test

Right. DAGCombine will insert *illegal* nodes before legalize. Evan On Jan 19, 2009, at 8:17 PM, Eli Friedman wrote: > On Mon, Jan 19, 2009 at 6:36 PM, Scott Michel <scottm at aero.org> wrote: >> I just ran across something interesting: DAGCombine inserts a 64-bit >> constant as the result of converting a (bitconvert (fabs val)) to a >> (and (bitconvert val),

Evan: And after legalize too. DAGCombine gets run after legalization. :-) -scooter On Jan 19, 2009, at 10:52 PM, Evan Cheng wrote: > Right. DAGCombine will insert *illegal* nodes before legalize. > > Evan > > On Jan 19, 2009, at 8:17 PM, Eli Friedman wrote: > >> On Mon, Jan 19, 2009 at 6:36 PM, Scott Michel <scottm at aero.org> >> wrote: >>> I

thomas weidner wrote: > Hello, > > i want to implement a common lisp subset using llvm for fun. Out of curiousity, for which CL implementation is this targeted? sbcl? Or something you're rolling? The reason why I ask is that I expressed an outrageous opinion at Supercomputing back in November, to wit, that CL is probably the best language suited for today's multicore

On Tue, Dec 30, 2008 at 8:59 PM, Scott Michel <scottm at aero.org> wrote: > On Dec 30, 2008, at 5:47 PM, Chris Lattner wrote: >> >> On Dec 30, 2008, at 5:24 PM, Scott Michel wrote: >> >>> Chris: >>> >>> On my _local_ x86_64 Ubuntu 7.10 machine, the shift_ops.ll is an >>> unexpected success (i.e., "grep -w shlh %t1.s | count

On Fri, Dec 12, 2008 at 11:42 AM, Scott Michel <scottm at aero.org> wrote: > The alternative is to do fairly deep inspection of brconds to eliminate the > truncate, which eventually gets expanded into: > (i8:sext_in_reg (i8:truncate (i32:setcc ...))) Have you tried implementing computeMaskedBitsForTargetNode for your setcc nodes? If you have, I think DAGCombiner should take care

On Mon, Jan 19, 2009 at 6:36 PM, Scott Michel <scottm at aero.org> wrote: > I just ran across something interesting: DAGCombine inserts a 64-bit > constant as the result of converting a (bitconvert (fabs val)) to a > (and (bitconvert val), i64const). > > The problem: i64 constants have to be legalized for the CellSPU > platform. DAGCombine is doing the right thing but

Anton Korobeynikov wrote: >>the official cutover. Granted, you might need darcs to pull the current >>version out of its repo, since it was originally designed with darcs in >>mind. > > I can confirm, that tailor converts LLVM CVS with all history preserved > to mercurial repository without any visible troubles. I'm not sure if I just took HEAD or converted the

Hello, Scott. > the official cutover. Granted, you might need darcs to pull the current > version out of its repo, since it was originally designed with darcs in > mind. I can confirm, that tailor converts LLVM CVS with all history preserved to mercurial repository without any visible troubles. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint

I've attached the .s file it produces in case you want to file a bug against grep. On Tue, Dec 30, 2008 at 10:36 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > On Tue, Dec 30, 2008 at 8:59 PM, Scott Michel <scottm at aero.org> wrote: >> On Dec 30, 2008, at 5:47 PM, Chris Lattner wrote: >>> >>> On Dec 30, 2008, at 5:24 PM, Scott Michel wrote:

I don't think llvm-gcc4 uses gccas or gccld, but it can emit bytecode if you give it the --emit-llvm option: llvm-gcc --emit-llvm -c -o foo.bc foo.c On 8/14/06, Scott Michel <scottm at rushg.aero.org> wrote: > I know that Al Stone has compiled llvm-gcc4 successfully and I can > report the same. The problem I consistently run into is that llvm-gcc > ends up producing native

Hello, i want to implement a common lisp subset using llvm for fun. This requires the use of a garbage collector. I read the docs, but many things are still unclear to me. 1. how are collectors supposed to find all living objects? there is llvm.gcroot for marking objects on the stack,but how do collectors crawl heap objects? I did not see a way to provide custom mark functions. Are