similar to: [LLVMdev] "grep -w" irregularity

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

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

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

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

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

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:

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 9" succeeds.) >> >> I get the same unexpected success on my x86_64 Mac 10.4.11. >> >> On

* Scott Michel: > 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. There have been issues the GNU libc

On Wed, Dec 31, 2008 at 3:35 AM, Florian Weimer <fw at deneb.enyo.de> wrote: > * Scott Michel: > >> 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

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

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

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),

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

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

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

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.

Hi Scott, I'm not clear on what you're saying here; some of your points below seem to be contradictory. The advice to use target-independent nodes when feasible seems sound to me, so I wrote up a comment about it in SelectionDAGNodes.h. If you can formulate your thoughts in the form of specific documentation changes, that would be helpful. In theory, DAGCombiner is supposed to check if