search for: sunits

...rote >> Bill Wendling wrote: >> >>> On Dec 30, 2008, at 4:51 PM, srs wrote: >>> >>> >>> >>>> 2. There seems to be an issue in ScheduleDAGSDNodes.h when in debug >>>> mode. The problem is the evaluation of "&SUnits[0];" which >>>> ASSERT's in >>>> VC++'s vector[] implementation (when _HAS_ITERATOR_DEBUGGING is on). >>>> >>>> As a work-around, I commented out the debug code (see "patch" >>>> below.) >>>> >>...

On Dec 31, 2008, at 5:57 AM, srs wrote: > Bill Wendling wrote: >> On Dec 30, 2008, at 4:51 PM, srs wrote: >> >> >>> 2. There seems to be an issue in ScheduleDAGSDNodes.h when in debug >>> mode. The problem is the evaluation of "&SUnits[0];" which >>> ASSERT's in >>> VC++'s vector[] implementation (when _HAS_ITERATOR_DEBUGGING is on). >>> >>> As a work-around, I commented out the debug code (see "patch" >>> below.) >>> >>> What would the prop...

Bill Wendling wrote: > On Dec 30, 2008, at 4:51 PM, srs wrote: > > >> 2. There seems to be an issue in ScheduleDAGSDNodes.h when in debug >> mode. The problem is the evaluation of "&SUnits[0];" which ASSERT's in >> VC++'s vector[] implementation (when _HAS_ITERATOR_DEBUGGING is on). >> >> As a work-around, I commented out the debug code (see "patch" below.) >> >> What would the proper solution be? The idiom appears to be allowed by...

...ix was to also link with JIT.obj (thanks aKor for pointing me in the right direction). I would have thought that linking with LLVMJIT.lib should suffice... a VC++ linker issue? 2. There seems to be an issue in ScheduleDAGSDNodes.h when in debug mode. The problem is the evaluation of "&SUnits[0];" which ASSERT's in VC++'s vector[] implementation (when _HAS_ITERATOR_DEBUGGING is on). As a work-around, I commented out the debug code (see "patch" below.) What would the proper solution be? The idiom appears to be allowed by the C++03 standard, but at least VC++ 20...

...ouly at gmail.com> > wrote: > > Hello, > > I was trying to interface a custom backend instruction scheduler with > llvm > > code when I realize something terrible. The scheduling code builds a > graph > > made up of SUnit * nodes (see ScheduleDAG*.{cpp,h}). These SUnits nodes > are > > allocated via a std::vector< SUnit >. > > This isn't a problem as long as the pointers are taken after the vector > is > > fully filled and the vector never changes its size. But the problem is > that > > is can happen ! > > Indeed, i...

Hello, I was trying to interface a custom backend instruction scheduler with llvm code when I realize something terrible. The scheduling code builds a graph made up of SUnit * nodes (see ScheduleDAG*.{cpp,h}). These SUnits nodes are allocated via a std::vector< SUnit >. This isn't a problem as long as the pointers are taken after the vector is fully filled and the vector never changes its size. But the problem is that is can happen ! Indeed, in some rare cases, the scheduler needs to duplicate a SUnit and t...

Right, later in the same file we have: // Reserve entries in the vector for each of the SUnits we are creating. This // ensure that reallocation of the vector won't happen, so SUnit*'s won't get // invalidated. // FIXME: Multiply by 2 because we may clone nodes during scheduling. // This is a temporary workaround. SUnits.reserve(NumNodes * 2); So for some reason *2 is...

...2:19 PM, Amaury Pouly <amaury.pouly at gmail.com> wrote: > Hello, > I was trying to interface a custom backend instruction scheduler with llvm > code when I realize something terrible. The scheduling code builds a graph > made up of SUnit * nodes (see ScheduleDAG*.{cpp,h}). These SUnits nodes are > allocated via a std::vector< SUnit >. > This isn't a problem as long as the pointers are taken after the vector is > fully filled and the vector never changes its size. But the problem is that > is can happen ! > Indeed, in some rare cases, the scheduler needs t...

On Dec 30, 2008, at 4:51 PM, srs wrote: > 2. There seems to be an issue in ScheduleDAGSDNodes.h when in debug > mode. The problem is the evaluation of "&SUnits[0];" which ASSERT's in > VC++'s vector[] implementation (when _HAS_ITERATOR_DEBUGGING is on). > > As a work-around, I commented out the debug code (see "patch" below.) > > What would the proper solution be? The idiom appears to be allowed by > the C++03 stan...

...ything - a fix is definitely possible, but I wonder what people think about it before I even consider this a bug. This looks like a bug. The edge order could even affect some heuristics and influence codegen. I don't have a better idea than using SetVector/MapVector for Value* keys. For SUnits we could just key on NodeNum. Go ahead and file a bug and/or submit a patch. Thanks! -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121017/6b30a33c/attachment.html>

Hello, I am working with the SelectionDAG/ScheduleDAG framework to implement a variation of the List scheduling Algorithm in LLVM. I was trying to understand the existing List scheduler implementation in LLVM. I have a doubt about the SUnits structure which contain flagged nodes together. The instructions within a Sunit are scheduled as a single unit. My understanding is that the nodes in the original DAG fall into exactly one of the Sunits. So, I was wondering if the instructions (SDNodes) within a SUnit need to be scheduled seperatel...

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

...ing anything – a fix is definitely possible, but I wonder what people think about it before I even consider this a bug. This looks like a bug. The edge order could even affect some heuristics and influence codegen. I don't have a better idea than using SetVector/MapVector for Value* keys. For SUnits we could just key on NodeNum. Go ahead and file a bug and/or submit a patch. Thanks! -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121016/48a22da7/attachment.html>

Andy, This is less of a question but rather a status quo verification. We currently have certain indeterminism in MI scheduler DAG construction - it is introduces by the use of std::map/std::set during edge traversal. Result - a random variation in SUnit edge order (which will remain fixed thereafter). Logically, it is the same DAG, but topologically it is a slightly different one,

Hello, Still trying to write a custom scheduler, I stumbled accross a highly suspicious code in all schedulers. In both ScheduleDAGFast.cpp and ScheduleDAGRRList.cpp, one can find this piece of code: SUnit *CopyFromSU = CreateNewSUnit(NULL); and then in the same files: SUnit *CreateNewSUnit(SDNode *N) { [...] SUnit *NewNode = NewSUnit(N); And finally in ScheduleDAGSDNodes.cpp: SUnit

Hi Gluster users, We are seeing 'error=No space left on device' issue and hoping someone might could advise? We are using a 12 node glusterfs v10.4 distributed vsftpd backup cluster for years (not new) and recently 2 weeks ago upgraded to v9 > v10.4. I do not know if the upgrade is related to this new issue. We are seeing a new issue 'error=No space left on device' error

Hi, xfs is supposed to detect the layout of a md-RAID devices when creating the file system, but it doesn?t seem to do that: # cat /proc/mdstat Personalities : [raid1] md10 : active raid1 sde[1] sdd[0] 499976512 blocks super 1.2 [2/2] [UU] bitmap: 0/4 pages [0KB], 65536KB chunk # mkfs.xfs /dev/md10p2 meta-data=/dev/md10p2 isize=512 agcount=4, agsize=30199892 blks

> Please try it out, run tests, build your favourite projects and file > bugs about anything that needs to be fixed, marking them as blockers > of http://llvm.org/pr31622. I have encountered very long compile times for three large source files containing generated/unrolled code at -O1. We are talking about 10+ hours here without completing, so it looks very much like an endless loop. The

Hi,Have you checked inode usage (df -i /lvbackups/brick ) ? Best Regards,Strahil Nikolov On Tuesday, May 2, 2023, 3:05 AM, brandon at thinkhuge.net wrote: Hi Gluster users, We are seeing 'error=No space left on device' issue and hoping someone might could advise? We are using a 12 node glusterfs v10.4 distributed vsftpd backup cluster for years (not new) and recently 2 weeks ago