[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/

Evan Cheng
2009-02-25T18:09:32Z

Things are still broken. Unfortunately llvm test suite does not
contain enough vector code to fully test this. Can you revert the
patch first?

Evan

On Feb 24, 2009, at 7:14 PM, Scott Michel wrote:

> Evan:
>
> I did not encounter this back trace before I committed the newest
> BuildVectorSDNode patch, which removed all class instance members
> and passes results back via reference parameters.
>
>
> -scooter
>
> On Tue, Feb 24, 2009 at 11:39 AM, Evan Cheng <evan.cheng at
apple.com>
> wrote:
> I believe this patch has broken a PPC app that I am tracking. Here
> is a reduced test case. Reproduce with llc -mattr=+Altivec -mcpu=g5.
> The backtrace looks like this:
>
> #0  0x9333ae42 in __kill ()
> #1  0x9333ae34 in kill$UNIX2003 ()
> #2  0x933ad23a in raise ()
> #3  0x933b9679 in abort ()
> #4  0x933ae3db in __assert_rtn ()
> #5  0x0008bd8f in llvm::MVT::getVectorElementType (this=0xbfffdda4)
> at ValueTypes.h:317
> #6  0x002aed06 in BuildSplatI (Val=0, SplatSize=8, VT={{V = 24,
> SimpleTy = llvm::MVT::v4i32, LLVMTy = 0x18}}, DAG=@0x16088a0,
> dl={Idx = 4294967295}) at PPCISelLowering.cpp:311\
> 5
> #7  0x002afae4 in llvm::PPCTargetLowering::LowerBUILD_VECTOR
> (this=0x1803d58, Op={Node = 0x157a530, ResNo = 0}, DAG=@0x16088a0)
> at PPCISelLowering.cpp:3200
> #8  0x002bb54f in llvm::PPCTargetLowering::LowerOperation
> (this=0x1803d58, Op={Node = 0x157a530, ResNo = 0}, DAG=@0x16088a0)
> at PPCISelLowering.cpp:3766
> #9  0x0051bed6 in (anonymous
> namespace)::SelectionDAGLegalize::LegalizeOp (this=0xbffff0e8,
> Op={Node = 0x157a530, ResNo = 0}) at LegalizeDAG.cpp:1608
> #10 0x0054837d in (anonymous
> namespace)::SelectionDAGLegalize::HandleOp (this=0xbffff0e8,
> Op={Node = 0x157a530, ResNo = 0}) at LegalizeDAG.cpp:519
> #11 0x005485a5 in (anonymous
> namespace)::SelectionDAGLegalize::LegalizeDAG (this=0xbffff0e8) at
> LegalizeDAG.cpp:389
> #12 0x00548734 in llvm::SelectionDAG::Legalize (this=0x16088a0,
> TypesNeedLegalizing=false, Fast=false) at LegalizeDAG.cpp:8648
> #13 0x005ec313 in llvm::SelectionDAGISel::CodeGenAndEmitDAG
> (this=0x1608780) at SelectionDAGISel.cpp:626
> #14 0x005ee7e2 in llvm::SelectionDAGISel::SelectBasicBlock
> (this=0x1608780, LLVMBB=0x1603fa0,
> Begin={<bidirectional_iterator<llvm::Instruction,int>> =
> {<std::iterator<std::bid\
> irectional_iterator_tag
> ,llvm::Instruction,int,llvm::Instruction*,llvm::Instruction&>> =
> {<No data fields>}, <No data fields>}, NodePtr = 0x1604dd0},
> End={<bidirectional_iterat\
> or<llvm::Instruction,int>> =
> {<
> std
> ::iterator
> <
> std
> ::bidirectional_iterator_tag
> ,llvm::Instruction,int,llvm::Instruction*,llvm::Instruction&>> =
> {<No data fields>}, <No data field\
> s>}, NodePtr = 0x16049e0}) at SelectionDAGISel.cpp:500
> #15 0x005ef123 in llvm::SelectionDAGISel::SelectAllBasicBlocks
> (this=0x1608780, Fn=@0x1603720, MF=@0x160d520, MMI=0x160bbd0,
> DW=0x1608fe0, TII=@0x1803ce0) at SelectionDAGISel.\
> cpp:856
> #16 0x005efe54 in llvm::SelectionDAGISel::runOnFunction
> (this=0x1608780, Fn=@0x1603720) at SelectionDAGISel.cpp:327
> #17 0x002a3aea in (anonymous
> namespace)::PPCDAGToDAGISel::runOnFunction (this=0x1608780,
> Fn=@0x1603720) at PPCISelDAGToDAG.cpp:54
> #18 0x00874127 in llvm::FPPassManager::runOnFunction
> (this=0x1606610, F=@0x1603720) at PassManager.cpp:1323
> #19 0x0087464c in llvm::FunctionPassManagerImpl::run
> (this=0x1606410, F=@0x1603720) at PassManager.cpp:1281
> #20 0x008747da in llvm::FunctionPassManager::run (this=0xbffff520,
> F=@0x1603720) at PassManager.cpp:1226
> #21 0x0000352e in main (argc=6, argv=0xbffff5d0) at llc.cpp:317
>
>
>
> Evan
>
> On Feb 24, 2009, at 9:35 AM, Scott Michel wrote:
>
>> Duncan:
>>
>> I'm still stymied how this whole thread ended up about shuffle
>> vector nodes, when the original problem was my build vector patch.
>> I'm still working on backing the build vector patch out (it
isn't
>> clean with all of the intervening commits and I have pressing
>> management tasks which command my attention.)
>>
>>
>> -scooter
>>
>> On Tue, Feb 24, 2009 at 12:28 AM, Duncan Sands <baldrick at
free.fr>
>> wrote:
>> > 3. Introduce a new ShuffleVectorSDNode that only has two SDValue
>> > operands (the two input vectors), but that also contains an array
>> of
>> > ints in the node (not as operands).
>> ...
>> > The important part of #3 is that we really want an array of ints
>> > (using -1 for undef) for the shuffle mask, not
"operands".  This
>> > eliminates the nastiness we have now were we need a buildvector,
>> and
>> > it eliminates the dance we have to prevent the build vector from
>> being
>> > legalized, and prevent the integer operands to it from being
>> legalized.
>>
>> This is PR2957 (which originally suggested a variadic SDNode, but it
>> quickly became clear that an array of ints is better).  It would be
>> great to have a volunteer for this (I don't have time).
>>
>> Ciao,
>>
>> Duncan.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090225/d5fd6ecf/attachment.html>