search for: priority_queu

We are having a strange issue with LLVM 2.6 running on MSVC in debug mode. When compiling in debug mode, iterator debugging is turned on. In the case of std::priority_queue, iterator debugging checks to make sure that the queue is in proper order and will abort if it isn't. Recently, we have started to see this error in the DAG. Call Stack: SelectionDAGISel::runOnMachineFunction:339 SelectionDAGISel::SelectAllBasicBlocks:401 SelectionDAGISel::CodeGenAndEmitDAG...

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: <http://lists.llvm.org/pipermail/llvm-dev/attachments/...

On May 25, 2010, at 2:58 PM, Smith, Tim wrote: > We are having a strange issue with LLVM 2.6 running on MSVC in debug mode. > > When compiling in debug mode, iterator debugging is turned on. In the case of std::priority_queue, iterator debugging checks to make sure that the queue is in proper order and will abort if it isn’t. > > Recently, we have started to see this error in the DAG. > > Call Stack: > > SelectionDAGISel::runOnMachineFunction:339 > SelectionDAGISel::SelectAllBasicBlocks:401 &...

On May 26, 2010, at 3:26 PM, Evan Cheng wrote: > > On May 25, 2010, at 2:58 PM, Smith, Tim wrote: > >> We are having a strange issue with LLVM 2.6 running on MSVC in debug mode. >> >> When compiling in debug mode, iterator debugging is turned on. In the case of std::priority_queue, iterator debugging checks to make sure that the queue is in proper order and will abort if it isn’t. >> >> Recently, we have started to see this error in the DAG. >> >> Call Stack: >> >> SelectionDAGISel::runOnMachineFunction:339 >> SelectionDAGISel...

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]': ScheduleDAGR...

I was studying the basic register allocator, and I am wondering why "LessSpillWeightPriority" priority was used over the greater weight. - Thanks Jeff Kunkel

On Oct 28, 2010, at 4:05 PM, Jeff Kunkel wrote: > I was studying the basic register allocator, and I am wondering why > "LessSpillWeightPriority" priority was used over the greater weight. Because the front of std::priority_queue is the largest element given the ordering.

...n <stoklund at 2pi.dk> wrote: > > On Oct 28, 2010, at 4:05 PM, Jeff Kunkel wrote: > >> I was studying the basic register allocator, and I am wondering why >> "LessSpillWeightPriority" priority was used over the greater weight. > > Because the front of std::priority_queue is the largest element given the ordering. > > >

...atch 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 CapturePred runs, it calls updateNode which does a std::make_heap on the underlying SUnitVec. This restores the correct ordering. I believe this should also make the scheduler run more like it is supposed to. Previously, the priority queue ordering was incorrect so we weren't necessar...

...Pixel() {x = 0; y = 0; intens = 0; }; Pixel(const Pixel& px) { x = px.x; y = px.y; intens = px.intens; }; Pixel(int i, int j, double val): x(i), y(j), intens(val) {}; }; bool operator < (const Pixel & a, const Pixel & b) { return a.intens < b.intens; }; typedef priority_queue<Pixel> PixelPrQueue; SEXP lib_filterInvWS (SEXP x) { SEXP res; int i, j, index; double val; PixelPrQueue pq; int nx = INTEGER ( GET_DIM(x) )[0]; int ny = INTEGER ( GET_DIM(x) )[1]; int nz = INTEGER ( GET_DIM(x) )[2]; int nprotect = 0; PROTECT (...

...asily separated from each other: - Node priority function (the SF parameter above). This is well-separated and easily changed. - Queue implementation. The current implementation uses a std::vector<> and has very bad asymptotic performance (N^2 currently). Previously this was a std::priority_queue<> but was changed because it missed some of the dynamic variance of node priorities. We have found it useful and essential to be able to replace this but even after inheriting from RegReductionPriorityQueue it's pretty ugly because there are two spearate queues in the scheduler,...

.... The customizations that you describe would all be handled by providing a new MachineSchedStrategy. Start by composing your scheduler from the pieces that are available, e.g. HazardChecker, RegisterPressure... (There's not much value providing a scheduling queue abstraction on top of vector or priority_queue). From that point, we can improve the design. Here's what you can expect in the MachineScheduler: 1. Precise register pressure tracking with back off. I'm in the process of checking in the pieces for this. It should be usable sometime in the next couple of weeks. 2. Division of the targ...

...wrote: >> >> On Oct 28, 2010, at 4:05 PM, Jeff Kunkel wrote: >> >>> I was studying the basic register allocator, and I am wondering why >>> "LessSpillWeightPriority" priority was used over the greater weight. >> >> Because the front of std::priority_queue is the largest element given the ordering. >> >> >> >

...uleDAGRRList. > > 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 CapturePred > runs, it > calls updateNode which does a std::make_heap on the underlying > SUnitVec. > This restores the correct ordering. > > I believe this should also make the scheduler run more like it is > supposed to. > Previously, the priority queue orde...

...be handled by providing a new > MachineSchedStrategy. Makes sense to me. > Start by composing your scheduler from the pieces that are available, > e.g. HazardChecker, RegisterPressure... (There's not much value > providing a scheduling queue abstraction on top of vector or > priority_queue). What do you mean by this last point? We absolutely want to be able to swap out different queue implementations. There is a significant compile time tradeoff to be made here. > 1. Precise register pressure tracking with back off. I'm in the > process of checking in the pieces for th...

...iosity what about top-down works better for your target? > >> Start by composing your scheduler from the pieces that are available, >> e.g. HazardChecker, RegisterPressure... (There's not much value >> providing a scheduling queue abstraction on top of vector or >> priority_queue). > > What do you mean by this last point? We absolutely want to be able to > swap out different queue implementations. There is a significant > compile time tradeoff to be made here. Use whatever data structure you like for your queue. I don't have plans to make a reusable one...

Hi Evans, Currently, we have not test all debug functionnalities, this will be done with the progress of our project. Could you explain more in details (by mail if possible) what is the problem with aggregates and debugging ? Could you also provide C program or llvm source file that exposes this problem in order to see what we can do? During our roadmap progress, FlexyCore will not hesitate to

I was trying to install ferret 0.9.2 on solaris (SunOS 5.8) which does not have a sys/dir.h nix_io.c:5:21: sys/dir.h: No such file or directory make: *** [nix_io.o] Error 1 I couldn''t find an obvious way around this... any suggestions? Thanks, Rich Marisa Cornell Information Technologies Cornell University

...i386-efi\pbkdf2.mod (1.5 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\pbkdf2_test.mod (2.2 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\pcidump.mod (2.5 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\play.mod (2.5 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\png.mod (7.4 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\priority_queue.mod (1.7 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\probe.mod (2.7 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\procfs.mod (2.2 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\progress.mod (2.1 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\raid5rec.mod (1.4 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\raid6rec.mod...

On 3/3/2016 07:43, Pete Batard via Syslinux wrote: > [...] as far as I am concerned, 'A "version" such as "6.03" [is not] > enough'. [...] I'd like to help to improve Syslinux with regards to version-related concerns. Having typed that, perhaps we could discuss your (or Rufus') specific needs, in parallel? Do I understand correctly that the primary