Thiago Martins via llvm-dev
2016-Jan-17 23:32 UTC
[llvm-dev] Open Projects - Code Generator Improvements #2
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 -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160117/7fee96f4/attachment.html>
Rafael EspĂndola via llvm-dev
2016-Jan-18 14:37 UTC
[llvm-dev] Open Projects - Code Generator Improvements #2
On 17 January 2016 at 18:32, Thiago Martins via llvm-dev <llvm-dev at lists.llvm.org> wrote:> 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). >For reference, that is ------------------------------------------------------------------ Implement 'stack slot coloring' to allocate two frame indexes to the same stack offset if their live ranges don't overlap. This can reuse a bunch of analysis machinery from LiveIntervals. Making the stack smaller is good for cache use and very important on targets where loads have limited displacement like ppc, thumb, mips, sparc, etc. This should be done as a pass before prolog epilog insertion. This is now done for register allocator temporaries, but not for allocas. ----------------------------------------------------------------- I think Hal Finkel has done some work on it. Cheers, Rafael
Philip Reames via llvm-dev
2016-Jan-21 21:40 UTC
[llvm-dev] Open Projects - Code Generator Improvements #2
We do have an existing stack coloring pass which runs on allocas. My understanding is that it's not very effective and relies on the existence of lifetime markers (i.e. it doesn't actually do any liveness analysis). I know that Keno Fischer has spent some time looking at the existing pass. I believe he was chasing down a mis-compile, but he's probably the most recent person to look at it. See: lib/CodeGen/StackColoring.cpp A very useful first step would be to consider merging StackColoring.cpp and StackSlotColoring.cpp. Philip On 01/18/2016 06:37 AM, Rafael EspĂndola via llvm-dev wrote:> On 17 January 2016 at 18:32, Thiago Martins via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> 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). >> > For reference, that is > > ------------------------------------------------------------------ > Implement 'stack slot coloring' to allocate two frame indexes to the > same stack offset if their live ranges don't overlap. This can reuse a > bunch of analysis machinery from LiveIntervals. Making the stack > smaller is good for cache use and very important on targets where > loads have limited displacement like ppc, thumb, mips, sparc, etc. > This should be done as a pass before prolog epilog insertion. This is > now done for register allocator temporaries, but not for allocas. > ----------------------------------------------------------------- > > I think Hal Finkel has done some work on it. > > Cheers, > Rafael > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Seemingly Similar Threads
- [LLVMdev] ARMv5 Thumb Support Hacking Session (and other topics)
- [LLVMdev] ARMv5 Thumb Support Hacking Session (and other topics)
- Allowing virtual registers after register allocation
- Unexpected behavior found in Stack Coloring pass, need clarification
- [LLVMdev] Problem of stack slot coloring