similar to: [LLVMdev] recent buildbot failure

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 it's not doing the right thing for CellSPU and it's damed difficult to work around this

No, I wasn't having a management lobotomy moment. If the target's registers have no subregisters, SubUsed is false and the assert gets tripped. Ok, back to the original question: What was the original intent in this code (lines 186-193 in lib/CodeGen/RegisterScavenging.cpp)? -scooter On Thu, Feb 25, 2010 at 7:00 PM, Scott Michel <scooter.phd at gmail.com> wrote: > Ugh.

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 9" succeeds.) I get the same unexpected success on my x86_64 Mac 10.4.11. On the x86_64 buildbot, the same test fails. The culprit is grep, evidently. It's just that simple. I suspect there's not really an issue with endianness, since all the

Ugh. Management lobotomy kicked in. Need to RTFC better. On Thu, Feb 25, 2010 at 6:18 PM, Scott Michel <scooter.phd at gmail.com> wrote: > There's an assert at line 192, lib/CodeGen/RegisterScavenging.cpp that > appears to get tripped on targets that don't have subregisters defined: > > bool SubUsed = false; > for (const unsigned *SubRegs =

There's an assert at line 192, lib/CodeGen/RegisterScavenging.cpp that appears to get tripped on targets that don't have subregisters defined: bool SubUsed = false; for (const unsigned *SubRegs = TRI->getSubRegisters(Reg); unsigned SubReg = *SubRegs; ++SubRegs) if (isUsed(SubReg)) { SubUsed = true; break; }

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

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

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

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

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

On 16 October 2015 at 15:17, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: > But if > there are new fails, the blame mailer can do a set-difference and report > only the new ones. That would reduce the noise a bit, hmm? Hi Paul, The danger there is that it'd be easier to "get used" to having some failures as long as you don't have "new"

After a hiatus on the CellSPU development, I've got all of the instructions necessary to get the llvm-gcc frontend to build. I've now discovered a new and interesting problem that I'm not sure how to solve cleanly and it's due to the fact that CellSPU has no fixed size condition flags. CellSPU's condition flags depend on the size of what's being compared, i.e., if both

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

Thank very much for this answer, so my last question will be: is it possible to use the LLVM JIT on a PS3 with Yellow Dog 6.2 distribution, instead of the LLVM interpreter, by using the PPE as it seems to be similar to 64-bit PowerPC processors? 2009/12/18 Scott Michel <scooter.phd at gmail.com> > Jerome: > > No, there are no plans to JIT to SPU. That's considerably more

On Aug 28, 2007, at 7:02 AM, Dan Gohman wrote: > On Mon, Aug 27, 2007 at 07:26:55PM -0700, Scott Michel wrote: >> It looks like I need to be able to intercept GEP lowering (in >> SelectionDAGLowering::visitGetElementPtr) and insert something else >> other than the shifts and adds. The basic problem is that CellSPU >> loads and stores on 16-byte boundaries. Consequently,

Scott, In case you missed it, I reimplemented your BuildVectorSDNode::isConstantSplat method following the suggestions from Chris. The revised version passes "make check" for llvm. Assuming that it also passes Evan's tests, I think it should also do what you need for CellSPU. On Feb 25, 2009, at 12:16 PM, Scott Michel wrote: > Evan: > > I work on reverting it,

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

It's yet another CellSPU thing: integer division is a long code sequence we have to insert that has branches within it (test for 0 divisor, etc.) Can't really emit the sequence of instructions via tblgen (can't have labels or BBs). The other alternative is a custom instruction emitter. Life could be easier if I could insert BRCONDs and other branches from within

It looks like I need to be able to intercept GEP lowering (in SelectionDAGLowering::visitGetElementPtr) and insert something else other than the shifts and adds. The basic problem is that CellSPU loads and stores on 16-byte boundaries. Consequently, the SPU backend has to do the load or store differently than most normal architectures that have byte-addressable operations.

Hi, I am currently trying to set up new performance and regression testers for Polly and LLVM and would like to XFAIL two test cases. I am using the LNTBuilder instead of the NightlyTestBuilder out of the assumption that the LNTBuilder is the more modern solution. However, when trying to xfail test cases I realized the xfail=[] parameter of getLNTFactor is ignored. Previously this was not an