search for: machinepointerinfo

Thank you for your suggestions. I implemented the first approach (provided the byval argument and offset to MachinePointerInfo) 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 getStor...

On Mar 15, 2012, at 10:22 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Thank you for your suggestions. > > I implemented the first approach (provided the byval argument and > offset to MachinePointerInfo) 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 orde...

On Mar 7, 2012, at 11:34 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > I filed a bug report (Bug 12205). > Please take a look when you have time. > > Per your suggestion, I also attached a patch which attaches to load or > store nodes a machinepointerinfo that points to a stack frame object > when it can infer they are actually reading from or writing to the > stack. The test that was failing passes if I apply this patch, but I > doubt this is the right approach, because this will fail if > InferPointerInfo in SelectionDAG.cpp cannot dis...

I filed a bug report (Bug 12205). Please take a look when you have time. Per your suggestion, I also attached a patch which attaches to load or store nodes a machinepointerinfo that points to a stack frame object when it can infer they are actually reading from or writing to the stack. The test that was failing passes if I apply this patch, but I doubt this is the right approach, because this will fail if InferPointerInfo in SelectionDAG.cpp cannot discover a load or stor...

...use non-extending load for element size less than 8bit on "DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT" like this roughly. > if (N->getOperand(0).getValueType().getVectorElementType().getSizeInBits() < 8) { > return DAG.getLoad(N->getValueType(0), dl, Store, StackPtr, MachinePointerInfo()); > } else { > return DAG.getExtLoad(ISD::EXTLOAD, dl, N->getValueType(0), Store, StackPtr, MachinePointerInfo(), EltVT); > } I assume that we need the opposite - if (.. < 8) getExtLoad // VT should be MVT::i8, MemVT should be MVT::i1 else getLoad - Elena From:...

...t<FrameIndexSDNode>(SpillSlot)->getIndex(); > SDValue Chain = CurDAG->getStore(CurDAG->getEntryNode(), > SpillVal.getDebugLoc(), > SpillVal, SpillSlot, > MachinePointerInfo::getFixedStack(FI), > false, false, 0); > Chain = CurDAG->getLoad(SpillVal.getValueType(), SpillVal.getDebugLoc(), > Chain, SpillSlot, > MachinePointerInfo::getFixedStack(FI), >...

...nding 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 should be computed? I use DAG.getFrameIndex((dyn_cast&...

...e need to use non-extending load for element size less than 8bit on "DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT" like this roughly. if (N->getOperand(0).getValueType().getVectorElementType().getSizeInBits() < 8) { return DAG.getLoad(N->getValueType(0), dl, Store, StackPtr, MachinePointerInfo()); } else { return DAG.getExtLoad(ISD::EXTLOAD, dl, N->getValueType(0), Store, StackPtr, MachinePointerInfo(), EltVT); } How do you think about it? Thanks, JinGu Kang On 15/09/2017 18:42, Demikhovsky, Elena wrote: extends the elements to 8bit and stores them on stack. Store is responsib...

Hi all, I met a new problem in the process of my project. I have got an address by mmap. And I want to build a MachineInstr of MOV64mr to move a value to the address. But it seems that the MachinePointerInfo needs a pointer to a Value. So can I create a MachineMemOperand directly with the address (is a long*) ? Or I need to try some other methods? Thanks a lot, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/2...

...FrameIndexSDNode>(SpillSlot)->getIndex(); > SDValue Chain = CurDAG->getStore(CurDAG->getEntryNode(), > SpillVal.getDebugLoc(), > SpillVal, SpillSlot, > > MachinePointerInfo::getFixedStack(FI), > false, false, 0); > Chain = CurDAG->getLoad(SpillVal.getValueType(), SpillVal.getDebugLoc(), > Chain, SpillSlot, > MachinePointerInfo::getFixedStack(FI), >...

...ation (if it exists) to do the translation. Thats perhaps not the cleanest implementation, but it would work. I was going to suggest that an alternative is to pass this information in to the load/store instructions in the backend, but it looks like that information is already available. That is, MachinePointerInfo has a getAddrSpace() method. This could potentially allow you to optimize MachineInstrs using the same knowledge you have here, e.g., constness for addrspace(3) in MachineLICM. > >> >> !address_spaces = !{!0, !1, !2, !3} >> >> ; Address space tuple. { address space n...

...) == 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()) { // Arguments passed in registers. const TargetRegisterClass *RC = ARC::CPURegsRegisterClass; unsigned int Register = MF.addLiveIn(VA.getLocReg(), RC); EVT RegisterValueType = VA.getLocVT(...

...ddress 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::i32 the code works but instead of a single byte store (STRB) I get a word store (STR). How can I force the width of the store? Thanks, Robert -------------- next part --...

...ill Lester via llvm-dev < > llvm-dev at lists.llvm.org>: > > Hi all, > > I met a new problem in the process of my project. > > I have got an address by mmap. And I want to build a MachineInstr of > MOV64mr > > to move a value to the address. But it seems that the MachinePointerInfo > > needs a pointer to a Value. > > So can I create a MachineMemOperand directly with the address (is a > long*) ? > > Or I need to try some other methods? > > Thanks a lot, > > Will > > > > _______________________________________________ > > LLVM...

.... 2018-04-16 16:25 GMT+08:00 Will Lester via llvm-dev <llvm-dev at lists.llvm.org>: > Hi all, > I met a new problem in the process of my project. > I have got an address by mmap. And I want to build a MachineInstr of MOV64mr > to move a value to the address. But it seems that the MachinePointerInfo > needs a pointer to a Value. > So can I create a MachineMemOperand directly with the address (is a long*) ? > Or I need to try some other methods? > Thanks a lot, > Will > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at list...

> extends the elements to 8bit and stores them on stack. Store is responsible for zero-extend. This is the policy... - Elena -----Original Message----- From: jingu at codeplay.com [mailto:jingu at codeplay.com] Sent: Friday, September 15, 2017 17:45 To: llvm-dev at lists.llvm.org; Demikhovsky, Elena <elena.demikhovsky at intel.com>; daniel_l_sanders at apple.com Subject: Re: Question

...UNCTION(); DebugLoc DL; if (MI != MBB.end()) DL = MI->getDebugLoc(); MachineFunction &MF = *MBB.getParent();MF.dump(); MachineFrameInfo &MFI = *MF.getFrameInfo(); unsigned Align = MFI.getObjectAlignment(MVT::i8); MachineMemOperand *MMO = MF.getMachineMemOperand(MachinePointerInfo::getFixedStack(MVT::i8), MachineMemOperand::MOStore, MFI.getObjectSize(MVT::i8), Align); BuildMI(MBB, MI, DL, get(Picoblaze::STORETOSTACK ));//.addMemOperand(MMO); if (RC == &Picoblaze::GR8RegClass) {...

...DAG.getConstant(SrcOff, MVT::i64))); // Ops.push_back(SrcPtrInfo.getWithOffset(SrcOff)); Ops.push_back(DAG.getConstant(0, MVT::i64)); Loads[i] = DAG.getNode(AArch64::FakeLoad64, dl, VT, Ops); There seems to be something wrong with pointer information inside getNode() as llvm::MachinePointerInfo::getAddrSpace() asserts. I can't find an example of similar instructions to start with, are there any similar pseudoes already? Any help would be appreciated, even if someone could confirm that it should be possible to do and I'm just missing something. Thanks, Sergey

...it exists) to do the translation. Thats perhaps not the cleanest implementation, but it would work. > > I was going to suggest that an alternative is to pass this information in to the load/store instructions in the backend, but it looks like that information is already available. That is, MachinePointerInfo has a getAddrSpace() method. This could potentially allow you to optimize MachineInstrs using the same knowledge you have here, e.g., constness for addrspace(3) in MachineLICM. From here: http://llvm.org/docs/LangRef.html#pointer-type "The semantics of non-zero address spaces are target-sp...

The code itself makes sense, but I want to know if this breaks any guarantee made about preserving a Value* in the MachineMemOperand. It sounds like we're having the same issue. We were using the Value* stored in the MachineMemOperand to get address space information during assembly printing. The alternative is carrying around a lot of extra (redundant) information in the SDAG. If it is