similar to: [LLVMdev] legalize dag problem

thanks for the help ..I do add the chain and the result. My code is like this ... SDValue Ops[] = { load->getChain(), load->getOperand(1), load->getBasePtr(), des }; DAG.getNode(CustomOpc, NodeTys, Ops, 4); thanks again! shrey On Thu, Nov 12, 2009 at 4:41 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> My problem is that the second call asserts inside

> My problem is that the second call asserts inside legalize ops at > ResultVals[Op.getResNo()]; b'cos ResultVals has only 1 element and > Op.resno is 0. Looks like you lowered the load improperly. It should return 2 values: the value loaded and a chain. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

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

> On Jan 23, 2017, at 12:36, Friedman, Eli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/23/2017 5:21 AM, Jonas Paulsson wrote: >> Hi Eli, >> >> I would like to clarify generally what the difference is between returning SDValue() and Op (input argument unchanged) from LowerOperation()? >> >> My understanding is that returning SDValue()

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

Evan: I work on reverting it, although, when I tried yesterday, it wasn't particularly clean (lots of rejected patches, presumably due to intervening commits.) Are you still getting the backtrace or is this just a case of incorrectly generated code? -scooter On Wed, Feb 25, 2009 at 10:09 AM, Evan Cheng <echeng at apple.com> wrote: > Things are still broken. Unfortunately llvm

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

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,

This isn't running in a child process, but this is a win32 machine. The problem I'm having is LegalizeOp is recursively calling itself 6 times, followed by 3 calls to ExpandEXTRACT_VECTOR_ELT, with each LegalizeOp pushing 20KBof data onto the stack and Expand pushing 800B of data on the stack. So that is 9 function calls pushing ~140KB of data onto the stack. This set of 9 function

I'm hitting an issue where legalizeOp is overflowing the stack. Are there any recommended ways of getting around this? The bitcode that causes this issue is attached. Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale, CA. 94085 P: 408-749-3966 -------------- next part -------------- An

Hey, I’ve been working on custom lowering ISD::UMUL_LOHI and ISD::SMUL_LOHI. Our target has some legal vector types but no support for these so would like to mark them as Expand. This yields “Cannot unroll a vector with multiple results!” from the default case in VectorLegalizer::Expand. Hence custom lowering. All the types are legal at this stage. I would appreciate some clarification on

Are you running with restricted stack size, e.g. in a pthread process? Evan On Mar 10, 2009, at 5:16 PM, Villmow, Micah wrote: > I’m hitting an issue where legalizeOp is overflowing the stack. Are > there any recommended ways of getting around this? > > The bitcode that causes this issue is attached. > > Thanks, > Micah Villmow > Systems Engineer > Advanced

On Sep 28, 2007, at 1:10 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com> wrote: > Attached please find the gdb backtrace dump and the postscript file of > the DAG right before assertion. > The red Node is the current Node in LegalizeOp() Okay, this is the problem. LegalizeOp should only be called on a node if the VT is valid for the target.

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

> 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

Hi, I wonder if anyone has any comment on a patch like: diff --git a/lib/CodeGen/SelectionDAG/InstrEmitter.cpp b/lib/CodeGen/SelectionDAG/InstrEmitter.cpp index 65ee3816f84..4780f6f0e59 100644 --- a/lib/CodeGen/SelectionDAG/InstrEmitter.cpp +++ b/lib/CodeGen/SelectionDAG/InstrEmitter.cpp @@ -243,18 +243,21 @@ void InstrEmitter::CreateVirtualRegisters(SDNode *Node,      if (!VRBase &&

LegalizeDAG.cpp SDOperand SelectionDAGLegalize::LegalizeOp(SDOperand Op) { case ISD::RET: Tmp1 = LegalizeOp(Node->getOperand(0)); // Legalize the chain. switch (Node->getNumOperands()) { case 2: // ret val [skipped] case 1: // ret void [skipped] default: { // ret <values> [skipped] Does it imply that a ret instruction may

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant