On Friday 04 January 2008 12:59, Evan Cheng wrote:> On Jan 2, 2008, at 12:44 PM, David Greene wrote: > > On Saturday 22 December 2007 02:33, Evan Cheng wrote: > >>> After some very simple testing, I see slowdowns of around 1.7%. I > >>> assume > >>> this is ok, but want to check. > >> > >> Can you clarify? Is this 1.7% slowdown of scheduling time or overall > >> codegen time? If it's the later, then it seems a bit too much. Also, > >> please test it with all the MultiSource/Applications. > > > > It's 1.7% overall. > > That seems somewhat steep. Can you see how much of the scheduling > slow down there is?I got some times from the nightly report, so this is overall compile time. The worst slowdown is on timberwolfmc "llc compile" which has a 5% slowdown. The JIT slows down 6%. Everything else looks to be 1% or less. In some cases the times with the change are better, probably because this change gets rid of the "pop everything off and push it back on" way of recreating the heap.[> The better way is to add a custom report for this. See > TEST.llc.Makefile and TEST.llc.report under llvm-test as an example. > You can do make TEST=llc to generate custom reports. If this change > can somehow be optionally controlled, then you can set it as llcbeta > option and write a custom report that compare the time spend in some > particular passes (TEST.beta-compare is an example, but it comparesf > number instructions).I'll look at this. But it would be nice to get this change (or something similar) in ASAP. The scheduler is just broken right now. So either we have a compiler with a slight slowdown in some cases or we have a compiler that exhibits undefined behavior.> The biggest problem is right now time spent in scheduling is lumped > into "DAG->DAG Instruction Selection" time because it's part of the > pass. It would be nice if we can somehow bring it out.Dunno if I can dig that deeply into this right now. I'll have to look at what's involved here. -Dave
On Monday 21 January 2008 10:41, David Greene wrote:> > >> Can you clarify? Is this 1.7% slowdown of scheduling time or overall > > >> codegen time? If it's the later, then it seems a bit too much. Also, > > >> please test it with all the MultiSource/Applications. > > > > > > It's 1.7% overall. > > > > That seems somewhat steep. Can you see how much of the scheduling > > slow down there is? > > I got some times from the nightly report, so this is overall compile time. > > The worst slowdown is on timberwolfmc "llc compile" which has a 5% > slowdown. The JIT slows down 6%. > > Everything else looks to be 1% or less. In some cases the times with > the change are better, probably because this change gets rid of the "pop > everything off and push it back on" way of recreating the heap.[Just want to send a ping on this. This patch is still waiting to go in. Is the compile time hit too much? Note that sometimes compile time improves with this patch. I'd like to get this in ASAP so I can start merging other things back to upstream. -Dave
Have you tested this on SPEC (especially spec2006)? JIT slow down of 6% is really too steep a price to pay. I'll test this patch when I find some time. Evan On Feb 4, 2008, at 9:31 AM, David Greene wrote:> On Monday 21 January 2008 10:41, David Greene wrote: > >>>>> Can you clarify? Is this 1.7% slowdown of scheduling time or >>>>> overall >>>>> codegen time? If it's the later, then it seems a bit too much. >>>>> Also, >>>>> please test it with all the MultiSource/Applications. >>>> >>>> It's 1.7% overall. >>> >>> That seems somewhat steep. Can you see how much of the scheduling >>> slow down there is? >> >> I got some times from the nightly report, so this is overall >> compile time. >> >> The worst slowdown is on timberwolfmc "llc compile" which has a 5% >> slowdown. The JIT slows down 6%. >> >> Everything else looks to be 1% or less. In some cases the times with >> the change are better, probably because this change gets rid of the >> "pop >> everything off and push it back on" way of recreating the heap.[ > > Just want to send a ping on this. This patch is still waiting to go > in. Is > the compile time hit too much? Note that sometimes compile time > improves with this patch. > > I'd like to get this in ASAP so I can start merging other things > back to > upstream. > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
David Greene wrote:> Just want to send a ping on this. This patch is still waiting to go in. Is > the compile time hit too much? Note that sometimes compile time > improves with this patch. > > I'd like to get this in ASAP so I can start merging other things back to > upstream. >Please see bug #2155, I am seeing an additional testsuite failure with ScheduleDAG patch. I am not saying there is any problem with ScheduleDAG patch itself, it may be just exposing a previously hidden bug. [I tried to add you to the Cc: of the bugreport, but bugzilla didn't find your email address] Best regards, --Edwin