search for: remapinstructions

...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 markerCoun...

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 ori...

...-------- 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 ori...

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(), > .... >...

...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 != VE;...

David, Peter, Let me try it one more time, now with an example… Short of upstreaming a fake function clone pass, let me only illustrate the issue in raw debug output. Hopefully it should be sufficient. Try this: clang -Os -g -fno-strict-aliasing test_arg_del.ll -mllvm -debug -mllvm -print-after-all After DAE - Removing argument 1 (reg) from foo DAE - Removing argument 2

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

...<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 = VMap.e...

> On 2014 Dec 10, at 08:40, Tom Stellard <tom at stellard.net> wrote: > > On Tue, Dec 09, 2014 at 09:22:16PM -0800, Duncan P. N. Exon Smith wrote: >> 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. >>

Hi All, the attached patch performs the splitting in the proposed manner. before applying 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

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

I have cloned an instruction from one basic block to another newly created block in newly created function. And since am cloning an instruction the operands of that instruction still points to the instructions of old block. Due to which am getting an error as "Instruction does not dominate all uses!". example:- original function and block:- %a = alloca i32, align 4 %x = alloca

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

> On 2014 Dec 10, at 14:08, Tom Stellard <tom at stellard.net> wrote: > > On Wed, Dec 10, 2014 at 11:21:08AM -0800, Duncan P. N. Exon Smith wrote: >> >>> On 2014 Dec 10, at 08:40, Tom Stellard <tom at stellard.net> wrote: >>> >>> On Tue, Dec 09, 2014 at 09:22:16PM -0800, Duncan P. N. Exon Smith wrote: >>>> The `Metadata`/`Value`

Hi John, On Thu, Nov 5, 2009 at 8:43 AM, John Criswell <criswell at uiuc.edu> wrote: > Does the debug facilities in LLVM TOT, at present, maintain information > better than LLVM 2.6 (i.e., if a front-end puts the debug information in, > will the optimizations not take it out)?  Does the information that the > llvm-gcc front-end adds comparable to what llvm-gcc in LLVM 2.6 does?

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,