On May 17, 2010, at 6:21 PM, Chris Lattner wrote:> > On May 17, 2010, at 5:43 PM, Jakob Stoklund Olesen wrote: > >> As you may have noticed, I have been working on a fast register allocator in the last week. The new allocator is intended to replace the local allocator for debug builds. > > This is great work Jakob! What is required and when do you think you'll be killing off the local allocator?I think we should switch clang -O0 to the fast allocator right away. It is the only way of smoking out the remaining bugs. I am not sure if or when llvm-gcc wants to switch, but when there are no more clients in the tree, we can kill off the local allocator. /jakob
You mention some potential issues on ARM, should we sort those out before we enable it in Clang? It's somewhat more convenient to have things be consistent. I propose that at some point you just replace the old local register allocator with the new one, and rename the old one. Then clients don't need to change, and we can keep the old one available for a little while if we want, for testing. - Daniel On Tue, May 18, 2010 at 7:49 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:> > On May 17, 2010, at 6:21 PM, Chris Lattner wrote: > >> >> On May 17, 2010, at 5:43 PM, Jakob Stoklund Olesen wrote: >> >>> As you may have noticed, I have been working on a fast register allocator in the last week. The new allocator is intended to replace the local allocator for debug builds. >> >> This is great work Jakob! What is required and when do you think you'll be killing off the local allocator? > > I think we should switch clang -O0 to the fast allocator right away. It is the only way of smoking out the remaining bugs. > > I am not sure if or when llvm-gcc wants to switch, but when there are no more clients in the tree, we can kill off the local allocator. > > /jakob > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On May 18, 2010, at 8:23 AM, Daniel Dunbar wrote:> You mention some potential issues on ARM, should we sort those out > before we enable it in Clang? It's somewhat more convenient to have > things be consistent.Sure, I'll be testing some ARM code today. There is also Evan's new REG_SEQUENCE instruction to verify.> I propose that at some point you just replace the old local register > allocator with the new one, and rename the old one. Then clients don't > need to change, and we can keep the old one available for a little > while if we want, for testing.I am not a big fan of renaming - it can easily cause confusion. Besides, fast-alloc goes with fast-isel. But perhaps we could take this opportunity to let LLVMTargetMachine choose a register allocator based on the optimization level? It is already enabling fast-isel that way, and -O0 -regalloc=linearscan (which is the default) doesn't really make sense. LLVMTargetMachine::addCommonCodeGenPasses does a decent job of building a codegen pipeline, except it needs help picking a register allocator. There is no good reason for that. /jakob
On May 18, 2010, at 7:49 AM, Jakob Stoklund Olesen wrote:> > On May 17, 2010, at 6:21 PM, Chris Lattner wrote: > >> >> On May 17, 2010, at 5:43 PM, Jakob Stoklund Olesen wrote: >> >>> As you may have noticed, I have been working on a fast register allocator in the last week. The new allocator is intended to replace the local allocator for debug builds. >> >> This is great work Jakob! What is required and when do you think you'll be killing off the local allocator? > > I think we should switch clang -O0 to the fast allocator right away. It is the only way of smoking out the remaining bugs. > > I am not sure if or when llvm-gcc wants to switch, but when there are no more clients in the tree, we can kill off the local allocator.Ok, but we should switch both clang and llvm-gcc at the same time. -Chris