similar to: [LLVMdev] Cell SPU backend status

Maybe it's because I've got a lot of two machine operand instructions and have to rely on the tied-to constraint, but I'm seeing a lot of dead reg-to-reg copy instructions, 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

As Andy Pinski pointed out, there were some really good reasons why Cell SPU support never made it into gcc 4.2. I've attached the patches from the 4.1.1 compiler, and I've applied+compiled them in my local tree. I suggested creating a branch, but since they appear to be relatively disjoint, the need for a branch doesn't seem necessary. Sorry for the large patch file -- I didn't

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

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

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

On Aug 13, 2007, at 9:11 PM, Chris Lattner wrote: > Nope, passes work within a module, they can't create/delete them. So there is no possibility to write a pass to arrange functions and globals in a different than the given way? No way to partition the structure new? I would really like to know how code is generated for heterogeneous architectures like Cell? I thought they use a

On a related note, I wrote a few scripts to detect and correct some types of such style errors, see llvm/utils/lint/* . I also added a function to llvm/utils/vim/vimrc to delete trailing whitespace and highlight existing trailing whitespace -- if anyone's an Emacs-lisp hacker, please add it to the emacs config file as well. Sure, this doesn't enforce anything, but I'm hoping folks

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

Chris Lattner skrev: > On Feb 22, 2010, at 6:08 AM, Kalle.Raiskila at nokia.com wrote: >> currently the SPU backend does not handle big stack frames (>16*511 >> bytes) nicely. llc asserts on malformed machine instructions. >> (Assertion `MI->getOperand(OpNo).isImm() && "printDFormAddr first >> operand is not immediate") > > Sounds fine

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

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

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

Hello > Would it be possible to conditionally enable the register scavenger only if > the function has a big stack? It now gets unconditionally enabled in >  SPURegisterInfo::requiresRegisterScavenging(const MachineFunction &MF). > Just checking MF.getFrameInfo()->getStackSize() here doesn't seem to be the > solution... Well, I think no. regscavenger should work well

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

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

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.

Jerome: No, there are no plans to JIT to SPU. That's considerably more complicated -- you'd have to figure out when to JIT to the SPU and live with all of the constraints that the SPU imposes (data reformatting, r/w DMA, ensure your code lives in 256K unless you can manage to interface with the virtual I-cache work.) Basically, it's not trivial and it doesn't quite fit into the

ComputeNumSignBits() is never called. Moreover, Cell SPU has to custom lower truncates in a specific way to preserve register uniformity (scalar and vector representation is one and the same, or, put another way, the scalar and vector registers are the same register.) Consequently, I can't trap (truncate (setcc ...)) patterns easily because the truncate is being custom lowered.

Background: The Cell SPU does not have condition registers in the normal sense. It fits the "zero or negative one" model, preferably with an i32 register, which is what getSetCCResultType() will return. Problem: LegalizeTypes promotes i1 to i8 via an i32 setcc, i.e., the generated type legalization is: (i8:truncate (i32:setcc i32:lhs, i32:rhs, ch:cond)) How do I keep