search for: remapinstruct

...ses, I have modified last few lines of runOnMachineFunction(..) method present in the StackColoring.cpp file. The original source can be found here: https://llvm.org/doxygen/StackColoring_8cpp_source.html bool StackColoring::runOnMachineFunction(MachineFunction &Func) { ... ... remapInstructions(SlotRemap); + bool markerCount = removeAllMarkers(); + DenseMap<int, int>::iterator itr = SlotRemap.begin(); + const AllocaInst *dInst = MFI->getObjectAllocation(itr->first); + LLVM_DEBUG(dbgs() << "Set break point here to inspect dInst\n"); + return marker...

The following 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...

...-------- From: Akira Hatanaka <ahatanak at gmail.com> Date: Wed, May 8, 2013 at 7:04 PM Subject: [PATCH] Minor fix to StackColoring to avoid needlessly clearing mem operands. To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> The following 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...

Hi Akira, did anything happen with this patch? Ciao, Duncan. On 09/05/13 04:04, Akira Hatanaka wrote: > The following 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(), > .... &gt...

...presenting variables to a <FrameIndex, DebugLoc> pair. All infos of all functions reside in a single map per module. In lib/CodeGen/StackColoring.cpp:493 is the only place where this information is updated (I am using LLVM 3.3, but the code seems to be the same in trunk). StackColoring::remapInstructions(DenseMap<int, int> &SlotRemap): // Remap debug information that refers to stack slots. MachineModuleInfo::VariableDbgInfoMapTy &VMap = MMI->getVariableDbgInfo(); for (MachineModuleInfo::VariableDbgInfoMapTy::iterator VI = VMap.begin(), VE = VMap.end(); VI !=...

...unction-attached metadata in the same way that we clone all other metadata. Differential Revision: http://reviews.llvm.org/D18583 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 264935 91177308-0d34-0410-b5e6-96231b3b80d8 we will have stale DISubprogram because RemapInstruction called from CloneFunctionInto() (here) // Loop over all instructions, fixing each one as we find it... for (Instruction &II : *BB) { RemapInstruction(&II, VMap, ModuleLevelChanges ? RF_None : RF_NoModuleLevelChanges, Typ...

Thank you for your help. It's working now. I wasn't aware of the usefulness of the User class. The ValueMapper.cpp's "RemapInstruction()" also helped me a lot to remap phi nodes and metadatas. Thank you very much. 2012/6/21 Michael Ilseman <michael at lunarg.com> > Please reply-all so that the thread is kept on llvmdev. > > The LLVM Programmer's Manual has examples of how to iterate over many > com...

...<ahatanak at gmail.com> > Date: Wed, May 8, 2013 at 7:04 PM > Subject: [PATCH] Minor fix to StackColoring to avoid needlessly clearing mem operands. > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > > > The following 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(), > .... >...

...reviewed yet. On Mon, May 13, 2013 at 8:50 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Akira, did anything happen with this patch? > > Ciao, Duncan. > > > On 09/05/13 04:04, Akira Hatanaka wrote: > >> The following 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-...

...bles to a <FrameIndex, DebugLoc> pair. All infos of all functions reside in a single map per module. > > In lib/CodeGen/StackColoring.cpp:493 is the only place where this information is updated (I am using LLVM 3.3, but the code seems to be the same in trunk). > > StackColoring::remapInstructions(DenseMap<int, int> &SlotRemap): > > // Remap debug information that refers to stack slots. > MachineModuleInfo::VariableDbgInfoMapTy &VMap = MMI->getVariableDbgInfo(); > for (MachineModuleInfo::VariableDbgInfoMapTy::iterator VI = VMap.begin(), > VE = VM...

...lueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () > from /opt/buildbot/lib/libLLVM-3.6svn.so > #12 0x00007ffff3427174 in llvm::RemapInstruction(llvm::Instruction*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () > from /opt/buildbot/lib/libLLVM-3.6svn.so >...

...lying the patch, please execute svn cp lib/Transforms/Scalar/LoopUnroll.cpp lib/Transforms/Utils/UnrollLoop.cpp to make the patch apply and preserve proper history. Transforms/Utils/UnrollLoop.cpp contains the unrollLoop function, which is now used by the LoopUnroll pass. I've also moved the RemapInstruction and FoldBlockIntoPredecessor support functions there. Additionally, I've also moved the loop unrolling statistics into the Utils file. Is that a good idea? I've added two new methods to Loop (or LoopBase<> really): getSmallConstantTripCount() and getSmallConstantTripMultiple(), w...

Hello All, I am having a problem with using CloneFunctionInto to clone a function that includes changing the type of a value using the VMap. Specifically, I am using the VMap to change the address space of values that have particular pointer types. The problem seems to be that RemapInstruction successfully changes the operands using the VMap, but the VTy member indicating the type of the instruction does not change to reflect the new types. In my case, this manifests itself as a GetElementPtr instruction (among others) that is accessing a value with a pointer in address space 1, but g...

...align 4 %4 = alloca i32, align 4 %5 = load i32* %x, align 4 %6 = mul nsw i32 %35, %36 %7 = add nsw i32 %mul17, %37 Now as we can see that operands of cloned instruction are still pointing to old block. How can I resolve this reference to make it point to new block only? I did see RemapInstruction and ValueMap, but being new to llvm I could not able to make proper use of it. So it would be great if you could help me implementing this. Thnx -- View this message in context: http://llvm.1065342.n5.nabble.com/How-to-fix-the-operand-references-of-cloned-instruction-tp62275.html Sent from t...

Hi, I want to copy some dependent statements, like a = b, b = c, from one basicblock to another basicblocks. Because of SSA, a = b, will be like %1 = load %b, store %1, %a. If I just use clone() method in Instruction class, it will be like <badref> = load %b, store <badref>, %a. If I need remap the virtual registers, this map just will affect the whole module? And how to use it? I am

The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the C++ side of it. This was a rocky day, but I suppose that's what I get for failing to stage the change in smaller pieces. As of r223916 (lldb), I'm not aware of any remaining (in-tree) breakage, so if I've missed some problem in the sea of buildbot errors, please flag me down. I'll follow up soon with

...:Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () >>> from /opt/buildbot/lib/libLLVM-3.6svn.so >>> #12 0x00007ffff3427174 in llvm::RemapInstruction(llvm::Instruction*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () >>> from /opt/buildbot/lib/libLLVM-3.6svn.s...

...!= NewBB->end(); ++I) { + if (TheCallMD && I->hasMetadata()) + if (MDNode *IMD = Context.getMetadata().getMD(DbgKind, I)) { + MDNode *NewMD = UpdateInlinedAtInfo(IMD, TheCallMD, Context); + Context.getMetadata().addMD(DbgKind, NewMD, I); + } RemapInstruction(I, ValueMap); + } } // Defer PHI resolution until rest of function is resolved, PHI resolution Index: Utils/InlineFunction.cpp =================================================================== --- Utils/InlineFunction.cpp (revision 86036) +++ Utils/InlineFunction.cpp (working copy) @...

Hello Matthijs, Separating mechanism from policy is a good thing for the LoopUnroll pass. Instead of moving the policy to a subclass though, I think it'd be better to move the mechanism, the unrollLoop function, out to be a standalone utility function, with the LoopInfo object passed in explicitly. FoldBlockIntoPredecessor would also be good to make into a standalone utility function, since

I will start from afar… When a dead function argument is removed, should we keep around the debug info for it? I have the following case: define internal fastcc void @foo(i8* %aa, i8* %reg, i8* %field, i32 %bb, ...) unnamed_addr #3 !dbg !28 { entry: call void @llvm.dbg.value(metabb i8* %aa, i64 0, metabb !34, metabb !47), !dbg !57 call void @llvm.dbg.value(metabb i8* %reg, i64 0,