search for: stackcoloring

This is the email I sent last week. ---------- Forwarded message ---------- 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 al...

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

The patch LGTM. The StackColoring patch is still too conservative and I am consulting with Jakob and Andy about possible solutions. On May 13, 2013, at 10:33 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > This is the email I sent last week. > > ---------- Forwarded message ---------- > From: Akira Hatanaka...

...ou are saying and I intend to move forward with the plan we agreed upon, which is, (1) disable the flag and find out what breaks, (2) fix the broken user code or compiler passes, (3) repeat. We also have three more things that we need to do: 1. We need to remove the inliner hack. I found that the StackColoring recovers 99% of the memory that is saved by the hack, but there are a few programs which still lose (allocate more stack space) when removing the hack. 2. We need to add a clang flag for disabling stack coloring. 3. We need to modify clang to generate more lifetime markers, not only when inlining....

...After digging around, I found that MachineModuleInfo has a VariableDbgInfo map, that is filled by SelectionDAGBuilder. MMI->VariableDbgInfo maps MDNodes representing 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::VariableDbgIn...

...g around, I found that MachineModuleInfo has a VariableDbgInfo map, that is filled by SelectionDAGBuilder. > MMI->VariableDbgInfo maps MDNodes representing 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. > MachineModule...

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

...t hasn't been 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...

Hello, I have come across an unusual behavior where instruction domination rule is violated "Instruction does not dominate all its uses." It concerns with StackColoring pass present at llvm/lib/CodeGen/StackColoring.cpp. I am reaching out to the LLVM community to help me understand the cause of this issue and the working of the pass. The IR produced at the end of the pass seems to be malformed.. Looking at transformed IR, it is clear that use of %0 precedes the d...

Hi from what I have figured out, the pass "TailCallElim" is being done in what I would call the "opt" phase of optimization. The "StackColoring" is being done in the "llc" phase. opt -> llc, so TailCallElim is always ahead. Now I would like to add something (my reusealloca idea) in "StackColoring" to get rid of some allocas, which inhibit "TailCallElim". * Is it possible to rerun (if even possible...

...e value received by use(a) will be the same. How I do understand the current the reference manual for llvm.lifetime.start, the semantics of llvm.lifetime.start(a) and if (c) llvm.lifetime.start(a) are the same if a is not used before that point. According to Than McIntosh the problem is that StackColoring currently does not correctly handle the situation. What I would wish for is that the language reference for lifetime markers is updated such that it reflects the what StackColoring can handle, and that the IR verifier fails when the lifetime markes are not well-formed according to that reference....

...g the contents of a MachineMemOperand? In particular, a MachineMemOperand has a Value associated with it for the original LLVM IR pointer, but is there any guarantee that this will be valid for *all* memory-touching instructions after isel and post-isel optimization? I found the following code in StackColoring that seems to indicate that one should not rely on the Value* in a MachineMemOperand to get at pointer information like address space during instruction printing since it may be NULL. 518 if (!V || !isa<AllocaInst>(V)) { 519 // Clear mem operand since we don't know for...

Hello, I am a student at UFMG, Brazil, and I'm currently choosing my final undergraduate project. I will be working under Professor Fernando Pereira (on cc), and we were thinking about tackling Code Generator Improvement number 2 (at http://llvm.org/OpenProjects.html). How is the status on this project? Is it still open? Thanks for your time, Thiago Martins. -------------- next part

...g the contents of a MachineMemOperand? In particular, a MachineMemOperand has a Value associated with it for the original LLVM IR pointer, but is there any guarantee that this will be valid for *all* memory-touching instructions after isel and post-isel optimization? I found the following code in StackColoring that seems to indicate that one should not rely on the Value* in a MachineMemOperand to get at pointer information like address space during instruction printing since it may be NULL. > > > 518 if (!V || !isa<AllocaInst>(V)) { > 519 // Clear mem operand since w...

2017-03-31 1:16 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: > if you transformed > > lifetime.start(%p) > use %p > lifetime.end(%p) > into > > if (c) > lifetime.start(%p) > use %p > lifetime.end(%p) > > That is *definitely* a bug in polly. > Stack coloring should be able to handle it if that is the original IR but that is definitely not a

...MachineMemOperand? In particular, > a MachineMemOperand has a Value associated with it for the original LLVM IR > pointer, but is there any guarantee that this will be valid for *all* > memory-touching instructions after isel and post-isel optimization? I > found the following code in StackColoring that seems to indicate that one > should not rely on the Value* in a MachineMemOperand to get at pointer > information like address space during instruction printing since it may be > NULL. > > > > > > 518 if (!V || !isa<AllocaInst>(V)) { > > 519...

With Debug mode, it shows the assert error: Assertion failed: (I != BlockLiveness.end() && "Predecessor not found"), function calculateLocalLiveness, file lib/CodeGen/StackColoring.cpp, line 782. 1. <eof> parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'busybox/archival/libarchive/decompress_bunzip2.c'. 4. Running pass 'Merge disjoint stack slots' on function '@read_bunzip' clang: error: unable...

...iven direction. Further more here mentioned 3 tasks may be not a much work for some one who has a good grasp on llvm but for me it may be sufficient for GSoC duration. It may not be possible for Google to provide fundings for limited number of improvements. So I am thinking to include some TODOs in StackColoring.cpp and StackSlotColoring.cpp in proposal too. Will it be enough to demonstrate in proposal ? Still I am looking for feedback on RDF part and also if some one is willing to mentor me. Sincerely, Vivek > Cheers. > > Tim. > -------------- next part -------------- An HTML attachment wa...

...osed stack maps are very different from LLVM’s gcroot because gcroot does not provide stack maps! llvm.gcroot effectively designates a stack location for each root for the duration of the current function, and forces the root to be spilled to the stack at all call sites (the client needs to disable StackColoring). This is really the opposite of a stack map and I’m not aware of any functionality that can be shared. It also requires a C++ plugin to process the roots. llvm.stackmap generates data in a section that MCJIT clients can parse. If someone wanted to use stack maps for GC, I don’t know why they woul...

...9;Function Pass Manager' on module 'busybox/archival/bzip2.c'. 4. Running pass 'Merge disjoint stack slots' on function '@mainSort' Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 clang 0x00000001011233c0 (anonymous namespace)::StackColoring::runOnMachineFunction(llvm::MachineFunction&) + 8448 1 clang 0x0000000100ff0746 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 134 2 clang 0x000000010124cdd2 llvm::FPPassManager::runOnFunction(llvm::Function&) + 546 3...