search for: scottm

...tone 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 \ --enable-llvm=/work/scottm/llvm/obj/i686-pc-linux-gnu/ \ --program-prefix=llvm- \ --disable-threads --disable-nls --disable-shared configure doesn't complain and the llvm object directory exists and is sane according to configure. Any clue?

...cc-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 light on what I should look at to track this one down? /Users/scottm/play/llvm/branches/llvm-spu/lib/CodeGen/SelectionDAG/ ScheduleDAG.cpp:406: failed assertion `I != VRBaseMap.end() && "Node emitted out of order - late"' -scooter -------------- next part -------------- A non-text attachment was scrubbed... Name: crtbegin.debug Type: appl...

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

...r) 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 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 wit...

...Results = 1 in { let isReturn = 1 in { def RET: BRForm<0b00010101100, (ops), "bi $$lr", BranchResolv, [(retflag)]>; } } Output from make: llvm[0]: Building SPU.td code emitter with tblgen tblgen: /work/scottm/llvm/utils/TableGen/CodeGenInstruction.h:118: std::pair<unsigned int, unsigned int> llvm::CodeGenInstruction::getSubOperandNumber(unsigned int) const: Assertion `i < OperandList.size() && "Invalid flat operand #"' failed. make: *** [/work/scottm/llvm/obj/i686-unknown-...

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 format output; it does not produce bytecode, > nor does it invoke gccas or gccld. > &gt...

...ions, e.g.: ori $3, $3, 0 (Cell SPU's version of reg-to-reg copy, looks a lot like PPC, no?) 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? -scooter -- Scott Michel scottm at aero.org High Performance Hardware Section Manager 310/336-5034 Computer Systems Research Department The Aerospace Corporation

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

On Tue, 9 Jan 2007, Evan Cheng wrote: >> - How does one deal with multiple instruction sequences in a pattern? >> To load a constant is a two instruction sequence, but both >> instructions only take two operands (assume that r3 is a 32-bit >> register): >> >> ilhu $3, 45 # r3 = (45 << 16) >> iohl $3, 5 # r3 |= 5

...RET: BRForm<0b00010101100, (ops), > "bi $$lr", > BranchResolv, > [(retflag)]>; > } > } > > Output from make: > > llvm[0]: Building SPU.td code emitter with tblgen > tblgen: /work/scottm/llvm/utils/TableGen/CodeGenInstruction.h:118: > std::pair<unsigned int, unsigned int> > llvm::CodeGenInstruction::getSubOperandNumber(unsigned int) const: > Assertion `i < OperandList.size() && "Invalid flat operand #"' failed. > make: *** > [/work/scot...

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

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 correct 9 expected occurances, whereas the x86_64 buildbot finds 10. Any

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

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

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

...s and new and didn't see anything regarding this. It appears to me to be a bug, can anyone confirm? -- ------------------------------------- Scott Machtmes, Sr. Systems Administrator Engineering Lab Services Infrastructure Lead Brocade 1745 Technology Drive San Jose, Ca. 95110 408-333-7203 scottm@brocade.com

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

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), i64const). >> >> The problem: i64 constants have to be legalized for the Cell...

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

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