similar to: [LLVMdev] RFC: GLIBCXX_DEBUG ScheduleDAG Patch

Hi Dave, This looks great to me! My only concern is the potential compile time impact. Do you see any? Also, please update the license portion to match what Chris sent out a couple of days ago. I don't see any issue with bringing Boost code into llvm tree. However, does it make sense to move the license to the top of the file? Chris? Evan On Dec 17, 2007, at 10:17 AM, David Greene

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

On Monday 17 December 2007 13:39, Evan Cheng wrote: > My only concern is the potential compile time impact. Do you see any? I don't notice any, but then I'm not particularly looking for that either. I'll run some tests. I also accidentally included some debugging code I added to track down this prioritization problem (the queue dumping code). I'll remove that before I

On Mon, 17 Dec 2007, David Greene wrote: > On Monday 17 December 2007 13:39, Evan Cheng wrote: >> My only concern is the potential compile time impact. Do you see any? > I don't notice any, but then I'm not particularly looking for that either. > I'll run some tests. Thanks. 5% slowdowns are generally not noticable, but we care :) > I also accidentally included

On Dec 20, 2007, at 2:43 PM, David Greene wrote: > On Monday 17 December 2007 19:48, Chris Lattner wrote: >> On Mon, 17 Dec 2007, David Greene wrote: >>> On Monday 17 December 2007 13:39, Evan Cheng wrote: >>>> My only concern is the potential compile time impact. Do you see >>>> any? >>> >>> I don't notice any, but then I'm

On Friday 04 January 2008 12:59, Evan Cheng wrote: > 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. Oops, I don't see these files. I just updated this morning. -Dave

>> 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. > > Oops, I don't see these files. I just updated this morning. They are in the test-suite module (aka llvm-test). -Tanya > > -Dave > _______________________________________________ > LLVM

On Monday 21 January 2008 03:54:22 pm Tanya M. Lattner wrote: > >> 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. > > > > Oops, I don't see these files. I just updated this morning. > > They are in the test-suite module (aka llvm-test). Yes, that's where I looked.

On Monday 17 December 2007 19:48, Chris Lattner wrote: > On Mon, 17 Dec 2007, David Greene wrote: > > On Monday 17 December 2007 13:39, Evan Cheng wrote: > >> My only concern is the potential compile time impact. Do you see any? > > > > I don't notice any, but then I'm not particularly looking for that > > either. I'll run some tests. > >

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

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

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

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

I'm reposting this patch at the request of Evan. It fixes a problem with std::priority_queue and _GLIBCXX_DEBUG. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: schedule_dag.diff Type: text/x-diff Size: 7731 bytes Desc: not available URL:

It's not building: usr/include/c++/4.0.0/bits/stl_queue.h: In member function 'void std::priority_queue<_Tp, _Sequence, _Compare>::push(const typename _Sequence::value_type&) [with _Tp = llvm::SUnit*, _Sequence = ll\ vm::container_reference_wrapper<std::vector<llvm::SUnit*, std::allocator<llvm::SUnit*> > >, _Compare = <unnamed>::td_ls_rr_sort]':

I'm debugging a ScheduleDAG problem. Somehow a load appearing before a call in the source gets scheduled after the call. Since the callee modifies the location loaded from, wrong answers result. Looking at the dag with -view-sched-dags, I don't see an edge from the load to depend on the call. How is this supposed to be handled by ScheduleDAG? -Dave

On Thu, Sep 3, 2009 at 9:48 AM, David Greene<dag at cray.com> wrote: > I'm debugging a ScheduleDAG problem.  Somehow a load appearing > before a call in the source gets scheduled after the call. > Since the callee modifies the location loaded from, wrong answers result. > > Looking at the dag with -view-sched-dags, I don't see an edge from the > load to depend on

On Thursday 03 September 2009 16:04, Eli Friedman wrote: > My first step would be to make sure there's an appropriate edge in the > selection DAG... there's a possibility something could get messed up > by legalization or the dagcombiner. I turned off dagcombine and it didn't help. > Since scheduling and selection is mostly within a block, hopefully it > wouldn't

On Thursday 03 September 2009 18:22, David Greene wrote: > > Since scheduling and selection is mostly within a block, hopefully it > > wouldn't be too hard to come up with a testcase? > > Yep, I've got a much reduced testcase now (and converted from Fortran > to C which makes things much easier to work with). I'm going to test > against TOT and see if I see

On Thursday 03 September 2009 20:41, Eli Friedman wrote: > > My little testcase definitely has missing edges in the sched dag and > > sunit dag.  Where do edges from loads of globals to calls get added? > >  That's what's missing here. > > They should be there from the very beginning, when the selection dag is > built. Nope, not there. I've attached the