search for: glibcxx_debug

Attached is a patch to fix a GLIBCXX_DEBUG error in ScheduleDAGRRList. The problem is that calls to CapturePred may reprioritize elements in the priority queue, violating streak weak ordering requirements. To fix this, I introduced a reference wrapper for containers to obtain access to the SUnitVec used by std::priority_queue. When Capt...

...tion 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 wrote: > Attached is a patch to fix a GLIBCXX_DEBUG error in ScheduleDAGRRList. > > The problem is that calls to CapturePred may reprioritize elements > in the > priority queue, violating streak weak ordering requirements. > > To fix this, I introduced a reference wrapper for containers to > obtain access > to the SUnitVe...

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

...ignificant register coalescing changes in the pipeline and I need to test them thoroughly before I commit. I also need to keep them current so I need to do frequent updates. This gets hard when updates break the compiler. These errors are usually trivial to fix as the problem is obvious from the GLIBCXX_DEBUG error output. It's just a matter of doing a build and test with --enable-expensive-checks. Most of the problems happen during llvm-gcc bootstrap so it's not even the case that the full testsuite needs to be run. Just a few sanity checks. -...

I'm seeing this when I run the fibonacci program via the win32 build. VRegInfo has size 0, and the debug STL in VStudio is asserting when &VRegInfo[0] is hit. Is anyone else seeing this? unsigned createVirtualRegister(const TargetRegisterClass *RegClass) { assert(RegClass && "Cannot create register without RegClass!"); // Add a reg, but keep track of