Andrew Trick <atrick at apple.com> writes:>> Ok, but that doesn't answer the question. Is SchedulerDAG going away? >> If so, what's the timeframe for that? 3.2? > > SchedulerDAG is used for both SD scheduling and MI scheduling. It's not going away.Oh! That's good news!> SD scheduling is not going away in 3.2--it will be the first release with MI scheduling on by default.Ok, that is helpful. Thanks!> If all goes well, I expect SD scheduling to be removed by 3.3. That has not been discussed.Is there any particular reason to remove it? Something has to convert from SDNodes to MachineInstrs so we'll at least need the "original order" SUnit scheduler, yes?> Here's a more complete list of the implementation steps, but the real > effort will be spent in performance analysis required before flipping > the switch. Don't expect it to be an adequate replacement out-of-box > for your benchmarks before 3.2.Understood.> - AliasAnalysis aware DAG option: In review (Sergei)This is going to be very important to us. I believe this accomplishes the same thing as Hal's patch and work we've done here. I'm really glad to see this here!> If you would simply like improved X86 scheduling without rolling your > own, then providing feedback and test cases is useful so we can > incorporate improvements into the standard scheduler while it's being > developed.Yep.>> Er, but as I understand it the MachineInstr scheduler will also use >> alias analysis. > > AliasAnalysis is important. We want it fully supported and enabled by > default, but that requires effort beyond simply enabling it. Today, > that effort is in the MI scheduler.Yes of course. Does this mean alias analysis in general will be available at the MachineInstr level? I've run into a desire for that multiple times.> The information I provided above is the best I can do, and as early as > I could provide this level of detail. If you follow trunk, you can see > the direction things are heading, but until recently I would not have > been able to tell you "plans" in the form of dates or release goals.This is really helpful, thanks! -Dave
On May 11, 2012, at 8:31 AM, dag at cray.com wrote:> Andrew Trick <atrick at apple.com> writes: > >> If all goes well, I expect SD scheduling to be removed by 3.3. That has not been discussed. > > Is there any particular reason to remove it? Something has to convert > from SDNodes to MachineInstrs so we'll at least need the "original > order" SUnit scheduler, yes?Correct. When MI scheduling is turned on for the first time, the existing SD scheduler will continue to run in "source order" mode. There are some difficult problems that come up when serializing SD nodes that have nothing to do with instruction scheduling per se. We want an SD serializer that handles those issues as simply and efficiently as possible, so we'll begin removing unnecessary complexity from the pass. We can resume this discussion post-3.2 when it becomes relevant.>> AliasAnalysis is important. We want it fully supported and enabled by >> default, but that requires effort beyond simply enabling it. Today, >> that effort is in the MI scheduler. > > Yes of course. Does this mean alias analysis in general will be > available at the MachineInstr level? I've run into a desire for that > multiple times.A trial implementation is almost in. If it proves to be sufficient, then we're done, and I'm prepared to support it. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120507/142662.html If you also want to continue developing the SelectionDAG scheduler for the next 6 months, then Hal's patch is a good start. There's not much benefit in checking that patch into trunk because it will be disabled, thus untested. That only makes sense if someone is actively working toward making it the default mode, otherwise filing llvm bugs on it would be counter-productive. If you just want to share code with other contributors there are other ways to do that. -Andy
Andrew Trick <atrick at apple.com> writes:> If you also want to continue developing the SelectionDAG scheduler for > the next 6 months, then Hal's patch is a good start. There's not much > benefit in checking that patch into trunk because it will be disabled, > thus untested. That only makes sense if someone is actively working > toward making it the default mode, otherwise filing llvm bugs on it > would be counter-productive. If you just want to share code with other > contributors there are other ways to do that.Mostly I would like to not have to keep applying custom patches to LLVM, but I realize that's not a strong reason for the rest of the community. Incidentally, what are those other ways to share code? -Dave