search for: memoperands_end

...smPrinter time? Where are they > stashed? Yes. There are some places where they aren't preserved, but otherwise they stick around for the entire CodeGen process. The places that don't preserve them should ideally be fixed eventually. They're available via the memoperands_begin()/memoperands_end() MachineInstr member functions. Dan

...tion", Machine Instruction dumps as below:   vr12<def> = LD_Iri %vr2<kill>, 0; mem:LD4[<unknown>]   I checked for memoperands for this MachInst, which are not empty, as "has_empty()" returns false. When I check "Value *", pointed by memoperands_begin() and memoperands_end(), i get NULL value. Thus, I don't the the memory pointer.   What can be probable reasons for this behavior? or is this behavior expected?   I have also checked in the lib/CodeGen/SelectionDAG/InstrEmitter.cpp, where MachineInstruction node is created from SDNode, but couldn't get much clu...

...MI are the same. The values can be different, so lets only check the sizes. + // If the sizes between one of the memoperands differ, then the instructions are + // not identical. + for (MachineInstr::mmo_iterator mb1 = memoperands_begin(), mb2 = Other->memoperands_begin() + me = memoperands_end(); mb1 != me; ++mb1, ++mb2) { + if (mb1->getSize() != mb2->getSize() || + mb1->getFlags() != mb2->getFlags() || + mb1->getOffset() != mb2->getOffset()) { + return false; + } + } + } + // Check operands to make sure they match. for (un...

...e values can be different, so lets only check the sizes. > + // If the sizes between one of the memoperands differ, then the instructions are > + // not identical. > + for (MachineInstr::mmo_iterator mb1 = memoperands_begin(), mb2 = Other->memoperands_begin() > + me = memoperands_end(); mb1 != me; ++mb1, ++mb2) { > + if (mb1->getSize() != mb2->getSize() || > + mb1->getFlags() != mb2->getFlags() || > + mb1->getOffset() != mb2->getOffset()) { > + return false; > + } > + } > + } > + > // Check...

On Monday 14 September 2009 12:32, David Greene wrote: > > The Offset->FrameIndex mapping seems rather heavy-weight, as > > any expense is incurred even when AsmVerbose is off. Would it > > be possible to use MachineMemOperands instead? In theory, > > they should already be preserving the needed information. If > > they're not sufficient, could they be

We'd like to be able to vary the latency of our load instructions based on what address space is being loaded from. I was thinking I could do this by overriding getOperandLatency in our target, but I'm wondering if the addrspace info is available when instructions are scheduled? For example, I have this in our llvm IR: %0 = load i32 addrspace(4)* @answer, align 4 store i32 %0, i32*

On Monday 14 September 2009 12:22, Dan Gohman wrote: > Hi Dave, > > On Sep 11, 2009, at 3:31 PM, David Greene wrote: > > Attached is a patch to print asm comments for spill information. > > We've discussed the mechanisms before but I wanted to run the > > patch by everyone before I start to commit pieces. > > The Offset->FrameIndex mapping seems rather

...et->getInstrInfo(); + + MachineFunction *MF = MBB->getParent(); + MachineRegisterInfo &MRI = MF->getRegInfo(); + MachineInstrBuilder MIB; + + // Memory Reference + MachineInstr::mmo_iterator MMOBegin = MI->memoperands_begin(); + MachineInstr::mmo_iterator MMOEnd = MI->memoperands_end(); + + MVT PVT = getPointerTy(MF->getDataLayout()); + unsigned PtrSize = PVT.getStoreSize(); + assert(PVT == MVT::i32 && "Invalid Pointer Size!"); + + unsigned Buf = MI->getOperand(0).getReg(); + unsigned JmpLoc = MRI.createVirtualRegister(&SP::IntRegsRegClass)...

Hi, I'm trying to implement __builtin_setjmp / __builtin_longjmp for Sparc processors. I think I'm very close, but I can't work out how to issue BuildMI-type instructions to load the address of the recovery location (set in setjmp) into a register using the SETHI / OR combination. I can't see any equivalent code anywhere else in Sparc. I imagine this is similar if I try to make a