search for: merge_valu

...ering. All the types are legal at this stage. I would appreciate some clarification on how custom lowering of nodes with multiple return values behaves. My theory is: - The lowering function is called once per ResNo - On each invocation, generate an SDValue for each ResNo - Generate an ISD::MERGE_VALUES nodes to combine all of these SDValues - Mutate the ResNo in the SDValue wrapping the ISD::MERGE_VALUES to match the input ResNo If that’s the right way to go, great. Confirmation would be appreciated. My first few attempts involved only generating an SDValue for the requested ResNo (which...

I'm trying to replace SDIvRem (whch returns two i16 types) with a custom that returns i32 or i16. I am getting the Assertion (!Node || ResNo < Node->getNumValues() && "Invalid result number for the given node!") Seems that it doesn't like returning one value but how do you return more than one value? I am doing this in the LowerOperation for the case SDIVREM and a

On Tuesday 24 February 2009 22:19:27 Arnold Schwaighofer wrote: > What i was trying to say is that if you have > > i32 a() { > %1 = tailcall b() > ret %1 > } > > > i32 b() { > %1 = tailcall c() > ret %1 > } > > i32 c() { > %1 = tailcall d() > ret %1 > } > > i32 d() { > ret i32 5 > } > > only d() will actually

...ons * - Instructions that may accept aggregate type, e.g., load, store, and select, must be split to handle the different component that compose a Value. (Look for the use of ComputeValueVTs in the SelecionDAGBuilder and the related loops this implies). - Use of aggregate type generates a bunch of MERGE_VALUE nodes, which sole purpose is to glue all the components that make the aggregate type together. Therefore, in practice, values with aggregate types are mapped to several SDValue hidden in MERGE_VALUE nodes. * Summary * Values with aggregate type map to a list of SDValue and, consequently, the ha...

...n't really care about the arguments, just want to get some global values working. When I trace the program, it is well passed the legalizing of formal arguments when it crashes so I'm not sure if I may be breaking something in there. Here is my code in the formalizing arguments (copied ISD::MERGE_VALUES from PowerPC implementation, not sure if it is really needed) static SDOperand LowerFORMAL_ARGUMENTS(SDOperand Op, SelectionDAG &DAG){ SmallVector<SDOperand, 8> ArgValues; SDOperand Root = Op.getOperand(0); // Return the new list of results. std::vector<MVT::ValueType> R...

0, i32 %1) >> >> Note that if you have a series of sequential recursive tail calls this >> move will only performed once (at the bottom of the recursion, >> respectively when the recursion returns) so it's impact on performance >> should be minimal. > > Hmm, that makes it sound as though the moves between a tail call and the > following return are

...eturns are represented internally by llvm (in the SelectionDAG) and how the tail call optimization implementation checks if it may perform the tail call. The implementation checks that the <call> node is immediately followed by a <ret> node. A struct return causes the insertion of a <merge_values> node between the tail call instruction and the return instruction node. Because of the intermediate node the backend believes it must not optimize the tail call. [result1, result2] = <call ... > [merged] = <merge_values [result1, result2]> <ret [merged]> So the current sit...

...The resulting output is SelectionDAG has 8 nodes: t0: ch = EntryToken t7: ch,glue = CopyToReg t10:1, Register:i16 %R25R24, t10 t2: i16,ch = CopyFromReg t0, Register:i16 %vreg0 t9: i16,i16,ch = LDWRdPtr<Mem:Volatile LD2[%1](align=1)(dereferenceable)> t2, t0 t10: i16,ch,i16 = merge_values t9, t9:2, t9:1 t8: ch = RET Register:i16 %R25R24, t7, t7:1 As you can see, even though the edges are correct, t7 should be after t10. This trips up LLVM further downstream: lib/CodeGen/SelectionDAG/InstrEmitter.cpp:303: unsigned int llvm::InstrEmitter::getVR(llvm::SDValue, llvm::Dens...

...0x8502b88: i32,ch = llvm.AMDIL.atomic.add.gi32.noret 0x8502a78, 0x8502b00, 0x8502280, 0x8502eb8 [ORD=6] [ID=19] And I generate this instruction: 0x8503160: i32 = AMDILISD::ATOM_G_ADD_NORET 0x8502a78, 0x8502280, 0x8502eb8, 0x8502f40 0x8502a78: <multiple use> 0x8503608: i32,ch = merge_values 0x8503160, 0x8502a78 What I'm trying to figure out is how I can generate this without the merge_values: 0x8503160: i32,ch = AMDILISD::ATOM_G_ADD_NORET 0x8502a78, 0x8502280, 0x8502eb8, 0x8502f40 I probably have other issues, but solving this should help me solve other issues. Thanks again, M...

...t aggregate type, e.g., load, store, and >> select, must be split to handle the different component that compose >> a Value. (Look for the use of ComputeValueVTs in the >> SelecionDAGBuilder and the related loops this implies). >> - Use of aggregate type generates a bunch of MERGE_VALUE nodes, which >> sole purpose is to glue all the components that make the aggregate >> type together. >> >> >> Therefore, in practice, values with aggregate types are mapped to >> several SDValue hidden in MERGE_VALUE nodes. >> >> >> * Summa...

Hi Nickhil, The Legalizer expects lower'd call is the node that produce the same number of values as the non-lowered node. That's what the assertion is checking. Take a look at the LowerCall routine for any other targets. You will see that in the non-void function case, it returns a MERGE_VALUES, i.e. all the results merged along with the chain. Cheers, Evan On Nov 15, 2006, at 3:30 AM, Nikhil Patil wrote: > Hi, > > I am trying to write a LowerCALL() function for my (custom) target > ISA. > All I need to do is map a CALL instruction directly onto an SDNode > th...

...#39;s > result > // type > SDValue Unpack[] = { SDValue(LDW, 0), SDValue(LDW, 2), > SDValue(LDW, 1) }; > SDNode* NN = CurDAG->getMergeValues(Unpack, SDLoc(N)).getNode(); Calling getMergeValues in ISelDAGToDAG is a bad idea; there aren't supposed to be any MERGE_VALUES nodes at that point in the pipeline. You can call ReplaceUses with SDValues rather than SDNodes. -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

...ld only be called on a node if the VT is valid for the target. In this case, ExpandOp should have been called to split the register up. I'd suggest going up the stack to figure out who called LegalizeOp instead of ExpandOp. > Here is my code in the formalizing arguments (copied ISD::MERGE_VALUES > from PowerPC implementation, not sure if it is really needed) MergeValues is required because the FORMAL_ARGUMENTs node returns one value for each argument input to the function, and also a chain value. These have to match up correctly. -Chris

Hi, I am trying to write a LowerCALL() function for my (custom) target ISA. All I need to do is map a CALL instruction directly onto an SDNode that takes an equal number of arguments (very much alike intrinsics, except that these are custom to my target.) I do not need to implement any call sequences, stack frames etc. I get the following assertion failure: llc: LegalizeDAG.cpp:834:

...r expects lower'd call is the node that produce the same > number of values as the non-lowered node. That's what the assertion > is checking. > > Take a look at the LowerCall routine for any other targets. You will > see that in the non-void function case, it returns a MERGE_VALUES, > i.e. all the results merged along with the chain. Sorry, I don't understand. I am only trying to look at functions that return void here (hence the RetVT == MVT::Other assertion near the end of my function). So, I think there should be only a single result - the SDOperand returned by...

On Sep 28, 2007, at 11:36 AM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com> wrote: > I moved my code to 2.1 but still the same. > If I make ADD i16 legal, then it goes through, but it has problem > expanding it to i8. > Should I go ahead and customize it and do the same for all > instructions? > Or there is a more general thing that I

...1_, align 8 %localStruct_ = alloca %struct_2 store %struct_2 %in1, %struct_2* %localStruct_, align 8 br label %exit exit: ; preds = %testFcn_entry ret void } [end example] It looks like at some stage of the backend compiler flow there is a "merge_values" instruction generated where the number of inputs exceeds 16k, but the number of inputs is stored in an unsigned short. When this instruction is being translated into x86 machine code, then there is an out of bounds access: ~> llc bug-simple.bc llc: /local/martind/oss/llvm-3.5.0.src/incl...

Drear there: The problem I have is to lower an intrinsic function like this ” float @llvm.write.arg(flaot %src, float* %dst) “ I am lowering it with INTRINSIC_W_CHAIN, so the return value and the value to write to dst are generated with some operations using src: " // it is the frame index node corresponding to input pointer SDvalue frindex = Op.getoperand(3); … SDValue returnValue =

...t; internally by llvm (in the SelectionDAG) and how the tail call > optimization implementation checks if it may perform the tail call. > The implementation checks that the <call> node is immediately followed > by a <ret> node. A struct return causes the insertion of a > <merge_values> node between the tail call instruction and the return > instruction node. Because of the intermediate node the backend > believes it must not optimize the tail call. > > [result1, result2] = <call ... > > [merged] = <merge_values [result1, result2]> > <ret [me...

I moved my code to 2.1 but still the same. If I make ADD i16 legal, then it goes through, but it has problem expanding it to i8. Should I go ahead and customize it and do the same for all instructions? Or there is a more general thing that I can do? A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: