search for: memoperands_begin

...o *MFI, if (!MIa->hasOneMemOperand() || !MIb->hasOneMemOperand()) return true; + // If mem-operands show that the same address Value is used by both + // ("normal") instructions, simply check offsets and sizes of the + // accesses. + MachineMemOperand *MMOa = *MIa->memoperands_begin(); + MachineMemOperand *MMOb = *MIb->memoperands_begin(); + const Value *VALa = MMOa->getValue(); + const Value *VALb = MMOb->getValue(); + if (VALa == VALb && + !MIa->hasUnmodeledSideEffects() && !MIb->hasUnmodeledSideEffects() && + !MIa->has...

...6ISelLowering.cpp (working copy) @@ -6010,7 +6010,9 @@ for (int i=0; i <= lastAddrIndx; ++i) (*MIB).addOperand(*argOpers[i]); MIB.addReg(t2); - + assert(bInstr->hasOneMemOperand() && "Unexpected number of memoperand"); + (*MIB).addMemOperand(*F, *bInstr->memoperands_begin()); + MIB = BuildMI(newMBB, TII->get(X86::MOV32rr), destOper.getReg()); MIB.addReg(X86::EAX); @@ -6107,6 +6109,8 @@ for (int i=0; i <= lastAddrIndx; ++i) (*MIB).addOperand(*argOpers[i]); MIB.addReg(t3); + assert(mInstr->hasOneMemOperand() && "Unexpected...

...lowing code snippet taken from StackColoring::remapInstructions clears a mem operand if it can't guarantee whether the memoperand's underlying value aliases with the merged allocas: // Update the MachineMemOperand to use the new alloca. 522 for (MachineInstr::mmo_iterator MM = I->memoperands_begin(), .... // Climb up and find the original alloca. 532 V = GetUnderlyingObject(V); 533 // If we did not find one, or if the one that we found is not in our 534 // map, then move on. 535 if (!V || !isa<AllocaInst>(V)) { 536 // Clear mem op...

...operands, make sure that the sizes of the memoperands for each + // 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; + } +...

...that the sizes of the memoperands for each > + // 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()) { > +...

...lowing code snippet taken from StackColoring::remapInstructions clears a mem operand if it can't guarantee whether the memoperand's underlying value aliases with the merged allocas: // Update the MachineMemOperand to use the new alloca. 522 for (MachineInstr::mmo_iterator MM = I->memoperands_begin(), .... // Climb up and find the original alloca. 532 V = GetUnderlyingObject(V); 533 // If we did not find one, or if the one that we found is not in our 534 // map, then move on. 535 if (!V || !isa<AllocaInst>(V)) { 536 // Clear mem op...

...rands available at AsmPrinter 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

On Nov 9, 2011, at 2:12 PM, Chris Lattner wrote: > On Nov 9, 2011, at 1:08 PM, Jim Grosbach wrote: >>> On Nov 9, 2011, at 10:49 AM, Jim Grosbach wrote: >>>>> >>>>> It's not good, but people do it. Also constructing enums via & and | etc. It'd be nice to be able to get the name of whatever it is that the code generator actually produced :)

...from StackColoring::remapInstructions clears a > mem operand if it can't guarantee whether the memoperand's underlying value > aliases with the merged allocas: > > // Update the MachineMemOperand to use the new alloca. > 522 for (MachineInstr::mmo_iterator MM = I->memoperands_begin(), > .... > // Climb up and find the original alloca. > 532 V = GetUnderlyingObject(V); > 533 // If we did not find one, or if the one that we found is not in our > 534 // map, then move on. > 535 if (!V || !isa<AllocaInst>(V...

Hi Jochen, > My llvm version is 3.0 release. > I have a module generated by clang. When I optimize it, I first add an > inlining pass (llvm::createFunctionInliningPass), then these passes: > - own FunctionPass > - llvm::createPromoteMemoryToRegisterPass > - llvm::createInstructionCombiningPass > - llvm::createDeadInstEliminationPass > - llvm::createDeadStoreEliminationPass

...ppet taken from StackColoring::remapInstructions clears a mem operand if it can't guarantee whether the memoperand's underlying value aliases with the merged allocas: > > // Update the MachineMemOperand to use the new alloca. > 522 for (MachineInstr::mmo_iterator MM = I->memoperands_begin(), > .... > // Climb up and find the original alloca. > 532 V = GetUnderlyingObject(V); > 533 // If we did not find one, or if the one that we found is not in our > 534 // map, then move on. > 535 if (!V || !isa<AllocaInst>(V)) {...

...>> clears a >> mem operand if it can't guarantee whether the memoperand's underlying >> value >> aliases with the merged allocas: >> >> // Update the MachineMemOperand to use the new alloca. >> 522 for (MachineInstr::mmo_iterator MM = I->memoperands_begin(), >> .... >> // Climb up and find the original alloca. >> 532 V = GetUnderlyingObject(V); >> 533 // If we did not find one, or if the one that we found is >> not in our >> 534 // map, then move on. >> 535 i...

Hi! My llvm version is 3.0 release. I have a module generated by clang. When I optimize it, I first add an inlining pass (llvm::createFunctionInliningPass), then these passes: - own FunctionPass - llvm::createPromoteMemoryToRegisterPass - llvm::createInstructionCombiningPass - llvm::createDeadInstEliminationPass - llvm::createDeadStoreEliminationPass - new llvm::DominatorTree() - new

...  For "load instruction", 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 cou...

...as() SDNode *SDN1; SDNode *SDN2; MachineMemOperand *MMOa; MachineMemOperand *MMOb; ... const MachineSDNode *MNb = dyn_cast<MachineSDNode>(SDN2); const MachineSDNode *MNa = dyn_cast<MachineSDNode>(SDN1); ... MMOa = !MNa->memoperands_empty() ? (*MNa->memoperands_begin()) : NULL; MMOb = !MNb->memoperands_empty() ? (*MNb->memoperands_begin()) : NULL; if (MMOa && MMOa->getValue() && MMOb && MMOb->getValue()) { ... int64_t MinOffset = std::min(MMOa->getOffset(), MMOb->getOffset()); i...

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

...e examples, I also realized I didn't have any examples for testing properties of the MachineMemOperand, so here's one: def mmo_is_load_8 : GIMatchPredicate< (ins instr:$A), (outs), [{ if (!${A}.hasOneMemOperand()) return false; const auto &MMO = *${A}.memoperands_begin(); return MMO.isLoad() && MMO.getSize() == 1; }]>; def : GICombineRule< (defs operand:$D, operand:$A), (match (G_LOAD $D, $A):$MI, (mmo_is_load8 instr:$MI)), (apply ...)>; I've made use of the naming instructions here since this was...

...any examples for testing properties of the MachineMemOperand, so here's one: >> def mmo_is_load_8 : GIMatchPredicate< >> (ins instr:$A), (outs), [{ >> if (!${A}.hasOneMemOperand()) >> return false; >> const auto &MMO = *${A}.memoperands_begin(); >> return MMO.isLoad() && MMO.getSize() == 1; >> }]>; >> def : GICombineRule< >> (defs operand:$D, operand:$A), >> (match (G_LOAD $D, $A):$MI, >> (mmo_is_load8 instr:$MI)), >> (apply ...)>; &g...

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