[LLVMdev] RFC: GLIBCXX_DEBUG ScheduleDAG Patch

[David Greene]

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