search for: getstore

...> > probably be factored out somewhere so the code can be shared. I > > reorganized SelectionDAGLowering::getLoadFrom a little, to make it > > simpler to use in other contexts. > > > > Also, the patch fixes a bug where SelectionDAG::getLoad and > > SelectionDAG::getStore were being called with the wrong arguments, > > with > > a default argument helping to hide it. > > Can you be more specific about what the bugs are? Sure. SelectionDAG::getStore and getLoad are declared like this: SDOperand getLoad(MVT::ValueType VT, SDOperand Chain, SDOpe...

...is use ANY_EXTEND if 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, +...

...xt 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, 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

...gt; @@ -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 >> + CalculateTailCallArgDes...

...with alias queries; it should > probably be factored out somewhere so the code can be shared. I > reorganized SelectionDAGLowering::getLoadFrom a little, to make it > simpler to use in other contexts. > > Also, the patch fixes a bug where SelectionDAG::getLoad and > SelectionDAG::getStore were being called with the wrong arguments, > with > a default argument helping to hide it. Can you be more specific about what the bugs are? Thanks, Evan > > I'm interested in any comments or feedback that people might have. > > Dan > > -- > Dan Gohman, Cray In...

...iner.cpp for using SDOperands with alias queries; it should probably be factored out somewhere so the code can be shared. I reorganized SelectionDAGLowering::getLoadFrom a little, to make it simpler to use in other contexts. Also, the patch fixes a bug where SelectionDAG::getLoad and SelectionDAG::getStore were being called with the wrong arguments, with a default argument helping to hide it. I'm interested in any comments or feedback that people might have. Dan -- Dan Gohman, Cray Inc. <djg at cray.com> -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/SelectionDA...

...t; // it is the frame index node corresponding to input pointer SDvalue frindex = Op.getoperand(3); … SDValue returnValue = DAG.getNode(myNode1, DL, VT….); SDValue dstValue = DAG.getNode(myNode2, DL, VT….); // to save the value to dst pointer, I think I need some call like SDValue dstOut = DAG.getStore(chain, DL, dstValue, FrameIndex, MachinePointerInfo(), false, false, 0); “ I have two questions here: (1) should I return some merges values( returnValue, DstValue) ? or only return returnValue is right? ( the dag dumped out looks better if I return the merged values) (2) How the FrameIndex sho...

While hacking around in the SelectionDAG build code, I've made the isVolatile, (new) isNonTemporal and Alignment parameters to SelectionDAG::getLoad/getStore and friends non-default. I've already caught one bug in the XCore backend by doing this: if (Offset % 4 == 0) { // We've managed to infer better alignment information than the load // already has. Use an aligned load. return DAG.getLoad(getPointerTy(), dl, Chain, Bas...

...h this for way too long now, so hopefully the mighty list can help: I am trying to generate a byte store instruction storing the constant value 4 at some given address in a new helper function inside ARMISelLowering.cpp I tried: SDValue Val = DAG.getConstant(4, MVT::i8); SDValue Store = DAG.getStore(chain, dl, Val, Addr, MachinePointerInfo(), false, false, 0); This gives me a a legalizer assert for MVT::i8. If I change it to MVT...

On Thursday 11 February 2010 17:40:24 David Greene wrote: > While hacking around in the SelectionDAG build code, I've made the > isVolatile, (new) isNonTemporal and Alignment parameters to > SelectionDAG::getLoad/getStore and friends non-default. > > I've already caught one bug in the XCore backend by doing this: > > if (Offset % 4 == 0) { > // We've managed to infer better alignment information than the load > // already has. Use an aligned load. > return DAG.getLo...

...terInfo) and it seems to have fixed the instruction ordering problem. It was a lot simpler than initially expected. In this particular case, is the user responsible for providing alias information to MachinePointerInfo to guarantee instructions are emitted in the correct order? It seems to me that getStore should not try to infer pointer information unless the user explicitly asks for it. The scheduler will then conservatively treat it as a load or store that aliases anything. On Mon, Mar 12, 2012 at 10:39 PM, Andrew Trick <atrick at apple.com> wrote: > > On Mar 7, 2012, at 11:34 AM, Aki...

...fixed the > instruction ordering problem. It was a lot simpler than initially > expected. > > In this particular case, is the user responsible for providing alias > information to MachinePointerInfo to guarantee instructions are > emitted in the correct order? It seems to me that getStore should not > try to infer pointer information unless the user explicitly asks for > it. The scheduler will then conservatively treat it as a load or store > that aliases anything. I think the pointer type inference is correct in the absence of any stronger information provided when the ta...

...e to apply the attached patch which changes MVT::ValueType (currently a uint32_t) into a one-element struct (the element being a uint32_t). This makes it harder to misuse MVT::ValueType. Thanks to this patch I found two cases in which the arguments to DAG.getConstant were inverted and one in which getStore was being passed an ValueType for the "volatile" argument. When I first started on this patch a few months ago I found several other similar examples which I fixed at the time. The other reason for applying it is that it gives better control over how the type is used, for example the DA...

...now which node to spill, perform the spill. > SDValue SpillVal = Node->getOperand(OpNo); > SDValue SpillSlot = CurDAG->CreateStackTemporary(SpillVal.getValueType()); > int FI = cast<FrameIndexSDNode>(SpillSlot)->getIndex(); > SDValue Chain = CurDAG->getStore(CurDAG->getEntryNode(), > SpillVal.getDebugLoc(), > SpillVal, SpillSlot, > MachinePointerInfo::getFixedStack(FI), > false, false, 0)...

Hi, Is it possible to add a spill code (a pair of store /load ) to the machinecode in a pass before the instruction emitter? If so, how can I calculate the address (offset to the sp) for the spill store/load instructions? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

...rand(0).getValueType(); unsigned OrigAlign = TLI.getTargetData()-> getABITypeAlignment(SVT.getTypeForMVT()); if (Align <= OrigAlign && ((!LegalOperations && !ST->isVolatile()) || TLI.isOperationLegalOrCustom(ISD::STORE, SVT))) return DAG.getStore(Chain, N->getDebugLoc(), Value.getOperand(0), Ptr, ST->getSrcValue(), ST->getSrcValueOffset(), ST->isVolatile(), OrigAlign); } Uhh...this doesn't seem legal to me. How can we just willy-nilly create a store with a greater ali...

...MVT::i32) && !LegalOperations && !ST->isVolatile()) || TLI.isOperationLegalOrCustom(ISD::STORE, MVT::i32)) { Tmp = DAG.getConstant((uint32_t)CFP->getValueAPF(). bitcastToAPInt().getZExtValue(), MVT::i32); return DAG.getStore(Chain, N->getDebugLoc(), Tmp, Ptr, ST->getPointerInfo(), ST->isVolatile(), ST->isNonTemporal(), ST->getAlignment()); } break; ------------- What would be the proper way to inhibit this change? In my target (...

...t that's probably ok. What exactly do you think is not possible? If finding the formal argument value and offset is too hard, I suppose there are other hacks you could try. I'm not encouraging it though. Is it valid to set MachinePointerInfo.V = 0? You could try overriding it after calling getStore. If that's not valid, you could probably create a PseudoSourceValue that aliases with everything. I suppose the hackiest thing would be marking the store volatile. The alternative would be to define a new MachineMemOperand flag. I really don't think we should have to go that far though. -A...

...now which node to spill, perform the spill. > SDValue SpillVal = Node->getOperand(OpNo); > SDValue SpillSlot = CurDAG->CreateStackTemporary(SpillVal.getValueType()); > int FI = cast<FrameIndexSDNode>(SpillSlot)->getIndex(); > SDValue Chain = CurDAG->getStore(CurDAG->getEntryNode(), > SpillVal.getDebugLoc(), > SpillVal, SpillSlot, > > MachinePointerInfo::getFixedStack(FI), > false, fals...