On May 3, 2011, at 12:03 PM, David A. Greene wrote:>> >> I am working my way through the regressions, looking for things the >> allocator did wrong. Any help is appreciated, please file bugs if you >> find examples of stupid register allocation. > > Certainly. I would ask that we keep linearscan around, if possible, as > long as there are significant regressions like this. Our customers tend > to really, really care about performance.That's reasonable, and it is also useful to keep it around as a reference when greedy breaks. On the other hand, I really want to clean up the code surrounding register allocation, and that is much easier to do after linear scan is gone. There is a good chance it won't make it to the 3.0 release. /jakob
Jakob Stoklund Olesen <stoklund at 2pi.dk> writes:> On May 3, 2011, at 12:03 PM, David A. Greene wrote:>> Certainly. I would ask that we keep linearscan around, if possible, as >> long as there are significant regressions like this. Our customers tend >> to really, really care about performance. > > That's reasonable, and it is also useful to keep it around as a reference when greedy breaks. > > On the other hand, I really want to clean up the code surrounding > register allocation, and that is much easier to do after linear scan > is gone. There is a good chance it won't make it to the 3.0 release.Believe me, I understand the desire to clean this code up. What's particular about linearscan in this regard? What parts are hard to clean up due to linearscan? -Dave
On May 3, 2011, at 3:24 PM, David A. Greene wrote:> Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >> On May 3, 2011, at 12:03 PM, David A. Greene wrote: > >>> Certainly. I would ask that we keep linearscan around, if possible, as >>> long as there are significant regressions like this. Our customers tend >>> to really, really care about performance. >> >> That's reasonable, and it is also useful to keep it around as a reference when greedy breaks. >> >> On the other hand, I really want to clean up the code surrounding >> register allocation, and that is much easier to do after linear scan >> is gone. There is a good chance it won't make it to the 3.0 release. > > Believe me, I understand the desire to clean this code up. What's > particular about linearscan in this regard? What parts are hard to > clean up due to linearscan?The new allocator doesn't use VirtRegRewriter. Deleting that alone will improve the average code quality significantly. The worst parts of LiveIntervalAnalysis.cpp can also be deleted. Once all that code is gone, it is much easier to refactor the LiveIntervals interface. /jakob
On May 3, 2011, at 1:30 PM, Jakob Stoklund Olesen wrote:> > On May 3, 2011, at 12:03 PM, David A. Greene wrote: > >>> >>> I am working my way through the regressions, looking for things the >>> allocator did wrong. Any help is appreciated, please file bugs if you >>> find examples of stupid register allocation. >> >> Certainly. I would ask that we keep linearscan around, if possible, as >> long as there are significant regressions like this. Our customers tend >> to really, really care about performance. > > That's reasonable, and it is also useful to keep it around as a reference when greedy breaks. > > On the other hand, I really want to clean up the code surrounding register allocation, and that is much easier to do after linear scan is gone. There is a good chance it won't make it to the 3.0 release.We designed the basic allocator as a baseline and intend to maintain it as a reference allocator. It factors the complexity out of the greedy allocator but otherwise provides the same interface to surrounding code. I don't think it will be long before LinearScan is more broken than GreedyRA, and BasicRA is the safer reference. Maybe Jakob didn't mention this because BasicRA is *temporarily* broken, but in a trivial way. The regressions occurred in highly unstable benchmarks. It's not as if we were monotonically improving these scores, and GreedyRA suddenly caused a regression. The point of looking into the regressions is to finally take control of this noise now that we have a better framework for doing so. -Andy