Hi,
Can anyone help me with the stack slot coloring optimization?
This corresponding file is /lib/codegen/stackslotcoloring.cpp.
It is said this optimization was for stack slot overlay for frame size
reduction, after register allocation phase.
And this transformation pass relies on the LiveStack analysis pass.
How, when checking the source code, it seems the LiveStack analysis has not
been implemented, since the code was found in LiveStackAnalysis.cpp:
*bool LiveStacks::runOnMachineFunction(MachineFunction &MF) {*
* TRI = MF.getTarget().getRegisterInfo();*
* // FIXME: No analysis is being done right now. We are relying on the*
* // register allocators to provide the information.*
* return false;*
*}*
And I found the greedy register allocator did nothing to fill the
LiveStackAnalysis::*S2IMap, *which is critical for the stack slot coloring.
Furthermore, the LiveInterval analysis only computes live intervals for
virtual registers, but not for stack slots which has frame indexes.
Does it mean this optimization has not been implemented yet ? And any
advice for me to do it by myself?
Or am I misunderstanding the implementation?
I really need some advice eagerly!
Any help is greatly appreciated!
--
Best regards,
Li Qingan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/24f2518b/attachment.html>
----- Original Message -----> From: "Qingan Li" <ww345ww at gmail.com> > To: llvmdev at cs.uiuc.edu > Sent: Monday, October 13, 2014 8:29:38 AM > Subject: [LLVMdev] Problem of stack slot coloring > > Hi, > > > Can anyone help me with the stack slot coloring optimization? > This corresponding file is /lib/codegen/stackslotcoloring.cpp. > > > It is said this optimization was for stack slot overlay for frame > size reduction, after register allocation phase. > And this transformation pass relies on the LiveStack analysis pass. > > > How, when checking the source code, it seems the LiveStack analysis > has not been implemented, since the code was found in > LiveStackAnalysis.cpp: > > > bool LiveStacks::runOnMachineFunction(MachineFunction &MF) { > TRI = MF.getTarget().getRegisterInfo(); > // FIXME: No analysis is being done right now. We are relying on the > // register allocators to provide the information. > return false; > } > > > And I found the greedy register allocator did nothing to fill the > LiveStackAnalysis:: S2IMap, which is critical for the stack slot > coloring.It seems that the relevant piece of code is in lib/CodeGen/InlineSpiller.cpp: /// spillAll - Spill all registers remaining after rematerialization. void InlineSpiller::spillAll() { // Update LiveStacks now that we are committed to spilling. if (StackSlot == VirtRegMap::NO_STACK_SLOT) { StackSlot = VRM.assignVirt2StackSlot(Original); StackInt = &LSS.getOrCreateInterval(StackSlot, MRI.getRegClass(Original)); StackInt->getNextValue(SlotIndex(), LSS.getVNInfoAllocator()); } else StackInt = &LSS.getInterval(StackSlot); if (Original != Edit->getReg()) VRM.assignVirt2StackSlot(Edit->getReg(), StackSlot); assert(StackInt->getNumValNums() == 1 && "Bad stack interval values"); for (unsigned i = 0, e = RegsToSpill.size(); i != e; ++i) StackInt->MergeSegmentsInAsValue(LIS.getInterval(RegsToSpill[i]), StackInt->getValNumInfo(0)); DEBUG(dbgs() << "Merged spilled regs: " << *StackInt << '\n'); And this is called by the register allocator in RAGreedy::selectOrSplitImpl. When the InlineSpiller calls LSS.getOrCreateInterval, that is a call to LiveStacks::getOrCreateInterval, and that updates the S2IMap inside of LiveStacks. -Hal> Furthermore, the LiveInterval analysis only computes live intervals > for virtual registers, but not for stack slots which has frame > indexes. Does it mean this optimization has not been implemented yet > ? And any advice for me to do it by myself? > Or am I misunderstanding the implementation? > > > I really need some advice eagerly! > Any help is greatly appreciated! > > > -- > Best regards, > > > Li Qingan > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
Hal's advice helps me a lot to understand the implementation much better. Thanks so much! So, now I am able to state my problem more clearly: 1) There are two kinds of locals, i.e., the local variables originated from the source code (like C/C++), and the compilation generated temporaries. After instruction selection phase, the former is seen as frame indexes, while the latter is seen as virtual registers. 2) The LiveInterval analysis computes the live intervals for virtual registers, which are then used for register allocation. 3) The register allocator spills some virtual registers as stack slot, and provides the information to LiveStack analysis, which is used for stack slot coloring. So, *it seems the stack slot coloring deals with only the compilation generated temporaries, but not the local variables from the source code.* Am I right? And, why it doesn't support the overlay of local variables? The reason is, it may do harm to the source code level debug? Or it involves complicated alias analysis? If I want to do it by myself, any further advice? 2014-10-13 23:32 GMT+08:00 Hal Finkel <hfinkel at anl.gov>:> > ----- Original Message ----- > > From: "Qingan Li" <ww345ww at gmail.com> > > To: llvmdev at cs.uiuc.edu > > Sent: Monday, October 13, 2014 8:29:38 AM > > Subject: [LLVMdev] Problem of stack slot coloring > > > > Hi, > > > > > > Can anyone help me with the stack slot coloring optimization? > > This corresponding file is /lib/codegen/stackslotcoloring.cpp. > > > > > > It is said this optimization was for stack slot overlay for frame > > size reduction, after register allocation phase. > > And this transformation pass relies on the LiveStack analysis pass. > > > > > > How, when checking the source code, it seems the LiveStack analysis > > has not been implemented, since the code was found in > > LiveStackAnalysis.cpp: > > > > > > bool LiveStacks::runOnMachineFunction(MachineFunction &MF) { > > TRI = MF.getTarget().getRegisterInfo(); > > // FIXME: No analysis is being done right now. We are relying on the > > // register allocators to provide the information. > > return false; > > } > > > > > > And I found the greedy register allocator did nothing to fill the > > LiveStackAnalysis:: S2IMap, which is critical for the stack slot > > coloring. > > It seems that the relevant piece of code is inlib/CodeGen/InlineSpiller.cpp:> > /// spillAll - Spill all registers remaining after rematerialization. > void InlineSpiller::spillAll() { > // Update LiveStacks now that we are committed to spilling. > if (StackSlot == VirtRegMap::NO_STACK_SLOT) { > StackSlot = VRM.assignVirt2StackSlot(Original); > StackInt = &LSS.getOrCreateInterval(StackSlot,MRI.getRegClass(Original));> StackInt->getNextValue(SlotIndex(), LSS.getVNInfoAllocator()); > } else > StackInt = &LSS.getInterval(StackSlot); > > if (Original != Edit->getReg()) > VRM.assignVirt2StackSlot(Edit->getReg(), StackSlot); > > assert(StackInt->getNumValNums() == 1 && "Bad stack interval values"); > for (unsigned i = 0, e = RegsToSpill.size(); i != e; ++i) > StackInt->MergeSegmentsInAsValue(LIS.getInterval(RegsToSpill[i]), > StackInt->getValNumInfo(0)); > DEBUG(dbgs() << "Merged spilled regs: " << *StackInt << '\n'); > > And this is called by the register allocator inRAGreedy::selectOrSplitImpl.> > When the InlineSpiller calls LSS.getOrCreateInterval, that is a call toLiveStacks::getOrCreateInterval, and that updates the S2IMap inside of LiveStacks.> > -Hal > > > Furthermore, the LiveInterval analysis only computes live intervals > > for virtual registers, but not for stack slots which has frame > > indexes. Does it mean this optimization has not been implemented yet > > ? And any advice for me to do it by myself? > > Or am I misunderstanding the implementation? > > > > > > I really need some advice eagerly! > > Any help is greatly appreciated! > > > > > > -- > > Best regards, > > > > > > Li Qingan > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory-- Best regards, Li Qingan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141014/fc29bba7/attachment.html>
Reasonably Related Threads
- [LLVMdev] Problem of stack slot coloring
- [LLVMdev] The type or size of virtual registers
- [LLVMdev] The type or size of virtual registers
- [LLVMdev] Is there a path from MachineInstr to the associated Instruction
- [LLVMdev] How to use LLVM optimizations with clang