search for: ptroff

...from the Pat. > My confusion is how operands of STWU from "Pat pre_store" get matched with those of memri. It is defined with operand types as: let MIOperandInfo = (ops dispRI:$imm, ptr_rc_nor0:$reg); while Pat is defined as: def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff), (STWU $rS, iaddroff:$ptroff, $ptrreg)>; So now how iPTR:$ptrreg and iaddroff:$ptroff get matched with ptr_rc_nor0:$reg and dispRI:$imm respectively? I mean the types are not exactly matching. Probably something is amiss in my understanding. -Anitha > > On 07/04/2013 10:...

Hi, How do "Pat" operands get matched? I am trying to follow the example given in http://llvm.org/docs/CodeGenerator.html#selectiondag-process In the latest trunk of ppcintrinfo.td following pattern is defined: def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff), (STWU $rS, iaddroff:$ptroff, $ptrreg)>; I understand that input operand list i.e. ins of stwu should get matched with the given pre_store. But I am confused as to how "ptroff" and "ptrreg" get matched with "memri" used in STWU? For reference[1] m...

...neither sext nor zext? @@ -1946,7 +2285,13 @@ SDOperand PPCTargetLowering::LowerCALL(SDOperand Op, SelectionDAG &DAG, if (GPR_idx != NumGPRs) { RegsToPass.push_back(std::make_pair(GPR[GPR_idx++], Arg)); } else { - MemOpChains.push_back(DAG.getStore(Chain, Arg, PtrOff, NULL, 0)); + if (!isTailCall) + MemOpChains.push_back(DAG.getStore(Chain, Arg, PtrOff, NULL, 0)); + // Calculate and remember argument location. + else + CalculateTailCallArgDest(DAG, MF, isPPC64, Arg, SPDiff, ArgOffset, +...

...-1946,7 +2285,13 @@ SDOperand > PPCTargetLowering::LowerCALL(SDOperand Op, SelectionDAG &DAG, > if (GPR_idx != NumGPRs) { > RegsToPass.push_back(std::make_pair(GPR[GPR_idx++], Arg)); > } else { > - MemOpChains.push_back(DAG.getStore(Chain, Arg, PtrOff, NULL, > 0)); > + if (!isTailCall) > + MemOpChains.push_back(DAG.getStore(Chain, Arg, PtrOff, > NULL, 0)); > + // Calculate and remember argument location. > + else > + CalculateTailCallArgDest(DAG, MF, isPPC64, Arg, SPDiff, > A...

Hello Dale, this is an updated version of the tail call optimization patch for powerpc. could you have a look at it? i added code to support ppc64 (untested, will try to get access to ppc64 on a friend's machine). incorporated evan's formatting suggestions. ;) will run another round of testing (llvm-test) on my powerpc g4/800 when i get the okay to commit. testing on this machine takes

...matched? I am trying to follow the example > given in http://llvm.org/docs/CodeGenerator.html#selectiondag-process > > In the latest trunk of ppcintrinfo.td <http://ppcintrinfo.td> > following pattern is defined: > > def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff), > (STWU $rS, iaddroff:$ptroff, $ptrreg)>; > > I understand that input operand list i.e. ins of stwu should get > matched with the given pre_store. But I am confused as to how > "ptroff" and "ptrreg" get matched with "memri" used in...

...13 @@ SDOperand >> PPCTargetLowering::LowerCALL(SDOperand Op, SelectionDAG &DAG, >> if (GPR_idx != NumGPRs) { >> RegsToPass.push_back(std::make_pair(GPR[GPR_idx++], Arg)); >> } else { >> - MemOpChains.push_back(DAG.getStore(Chain, Arg, PtrOff, NULL, >> 0)); >> + if (!isTailCall) >> + MemOpChains.push_back(DAG.getStore(Chain, Arg, PtrOff, >> NULL, 0)); >> + // Calculate and remember argument location. >> + else >> + CalculateTailCallArgDest(DAG, MF, isPPC64,...

...gsToPass.push_back(std::make_pair(VA.getLocReg(), Arg)); } else { // Sanity check. assert(VA.isMemLoc()); // Get the stack pointer if needed. if (StackPtr.getNode() == 0) { StackPtr = DAG.getCopyFromReg(Chain, dl, ARC::SP, getPointerTy()); } SDValue PtrOff = DAG.getNode(ISD::ADD, dl, getPointerTy(), StackPtr, DAG.getIntPtrConstant(VA.getLocMemOffset())); MemOpChains.push_back(DAG.getStore(Chain, dl, Arg, PtrOff, MachinePointerInfo(),false, false, 0)); } ... [2]: LowerFormalArguments ... if (VA.isRegLoc()) { //...

...1, 181, (outs ptr_rc_nor0:$ea_res), (ins g8rc:$rS, memrr:$dst), "stdux $rS, $dst", LdStSTDU, []>, RegConstraint<"$dst.ptrreg = $ea_res">, NoEncode<"$ea_res">; } def : Pat<(pre_store i64:$rS, iPTR:$ptrreg, iPTR:$ptroff), (STDUX $rS, $ptrreg, $ptroff)>; Note that the instruction has a pseudo-output operand $ea_res which is constrained and not encoded. You are correct, however, that this does not encode any information on the relationship between the input and output value. That is done only at the SD...

...$ea_res), (ins g8rc:$rS, memrr:$dst), > "stdux $rS, $dst", LdStSTDU, []>, > RegConstraint<"$dst.ptrreg = $ea_res">, NoEncode<"$ea_res">; > } > > def : Pat<(pre_store i64:$rS, iPTR:$ptrreg, iPTR:$ptroff), > (STDUX $rS, $ptrreg, $ptroff)>; > > Note that the instruction has a pseudo-output operand $ea_res which is constrained and not encoded. You are correct, however, that this does not encode any information on the relationship between the input and output value. That is done...

Hi Hal, Our Architecture has indirect move instruction which increments the pointer implicitly and the target only has i8 type values. So the load of i16 will be converted to two i8 target loads wherein after the first load instruction, the pointer to the first i8 address will automatically increment to point to the next i8 value. So the post increment nature is in the Target. A normal

...t in the LowerCall function in ISelLowering.cpp, there's this code (From the MIPS target): * // Create the frame index object for this incoming parameter LastFI = MFI->CreateFixedObject(ValVT.getSizeInBits()/8, VA.getLocMemOffset(), true); SDValue PtrOff = DAG.getFrameIndex(LastFI, getPointerTy());* This looks like what I might want to change, but I'm not sure what's the right thing to do. Here's what I tried to change it to: * LastFI = MFI->CreateStackObject(ValVT.getSizeInBits()/8, VA.getLocMemO...

...e<"$ea_result">; I now get an "Unknown node flavor used in pattern: ptr_rc_wrapper". I.e.: llvm[3]: Building PPC.td instruction information with tblgen STBU: (set ptr_rc_wrapper:<empty>:$ea_res, (ist:iPTR GPRC:i32:$rS, ptr_rc_wrapper:iPTR:$ptrreg, iaddroff:iPTR: $ptroff)<<P:Predicate_itruncstore>><<P:Predicate_pre_truncst>><<P:Predicate_pre_truncsti8>>) Included from /home/willschm/dev/llvm.gitmirror/llvm/lib/Target/PowerPC/PPC.td:68: /home/willschm/dev/llvm.gitmirror/llvm/lib/Target/PowerPC/PPCInstrInfo.td:825:1: error: In STBU...

Hi all, I've been poking at AsmParser support for powerpc64 (ppc64-elf-linux-abi) and have run into some behavior I don't understand with the ptr_rc references coming out of the PPC*.td files when generating the asm-matcher files. For instance : $ ./build/bin/llvm-tblgen llvm/lib/Target/PowerPC/PPC.td -I ~/llvm-head/llvm/include -I ~/llvm-head/llvm/lib/Target/PowerPC/ -gen-asm-matcher

...gt; > I now get an "Unknown node flavor used in pattern: ptr_rc_wrapper". > I.e.: > llvm[3]: Building PPC.td instruction information with tblgen > STBU: (set ptr_rc_wrapper:<empty>:$ea_res, (ist:iPTR GPRC:i32:$rS, > ptr_rc_wrapper:iPTR:$ptrreg, iaddroff:iPTR: > $ptroff)<<P:Predicate_itruncstore>><<P:Predicate_pre_truncst>><<P:Predicate_pre_truncsti8>>) > Included > from /home/willschm/dev/llvm.gitmirror/llvm/lib/Target/PowerPC/PPC.td:68: > /home/willschm/dev/llvm.gitmirror/llvm/lib/Target/PowerPC/PPCInstrInfo.td:825:1:...