search for: sunit

...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.) >>>> >&gt...

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 pro...

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 b...

...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++ 2...

...ug 8, 2010 at 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 > t...

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 case...

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 i...

...n NDEBUG is set. Eugene On Sun, Aug 8, 2010 at 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 ! >...

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 sta...

...So if it is not a feature. then couple questions: First, I also do not see an easy way to restructure work sets in this case - so let's assume std::map is needed here. Then the way I understand it, there are five objects that cause the indeterminism: std::map<const Value *, SUnit *> AliasMemDefs, NonAliasMemDefs; std::map<const Value *, std::vector<SUnit *> > AliasMemUses, NonAliasMemUses; std::set<SUnit*> RejectMemNodes; .since all of them at different point of time are traversed begin to end, and as such are affected by pointer value. Th...

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 seperate...

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]': ScheduleDAGRRList.cpp:1057: instantiated from 'void<unnamed>::RegReductionPriorityQueue<SF>::push(ll...

...te: > > 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, and if some algorithm is dependent on the order of edge traversal, we can have performance and debugging indeterminism. The way I have discovered it – VLIW scheduler can...

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, and if some algorithm is dependent on the order of edge traversal, we can have performance and debugging indeterminism. The way I have discovered it - VLIW scheduler can...

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 *ScheduleDAGSDNodes::NewSUnit(SDNode *N) { [...] if (N->isMachineOpcode() && [...] So basic...

...ybaknode9.example.net:/lvbackups/brick TCP Port : 60039 RDMA Port : 0 Online : Y Pid : 1664 File System : xfs Device : /dev/mapper/vgbackups-lvbackups Mount Options : rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,sunit=512,swidth=512,noquot a Inode Size : 512 Disk Space Free : 6.1TB Total Disk Space : 29.0TB Inode Count : 3108974976 Free Inodes : 3108881513 ---------------------------------------------------------------------------- -- Brick : Brick nybaknode11....

...isize=512 agcount=4, agsize=30199892 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0, sparse=0 data = bsize=4096 blocks=120799568, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=58984, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0...

...bout 10+ hours here without completing, so it looks very much like an endless loop. The processes are using 15, 22 and 27 GB of memory but do not appear to grow further. This worked fine in the past, so appears to be a regression. These stacks seem to be prevalent: #0 0x0000000001850588 in llvm::SUnit::addPred(llvm::SDep const&, bool) () #1 0x0000000001855265 in llvm::ScheduleDAGInstrs::addChainDependency(llvm::SUnit*, llvm::SUnit*, unsigned int) () #2 0x0000000001855519 in llvm::ScheduleDAGInstrs::addChainDependencies(llvm::SUnit*, llvm::ScheduleDAGInstrs::Value2SUsMap&) () #3 0x0000...

...k nybaknode9.example.net:/lvbackups/brick TCP Port? ? ? ? ? ? : 60039 RDMA Port? ? ? ? ? ? : 0 Online? ? ? ? ? ? ? : Y Pid? ? ? ? ? ? ? ? ? : 1664 File System? ? ? ? ? : xfs Device? ? ? ? ? ? ? : /dev/mapper/vgbackups-lvbackups Mount Options? ? ? ? : rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,sunit=512,swidth=512,noquot a Inode Size? ? ? ? ? : 512 Disk Space Free? ? ? : 6.1TB Total Disk Space? ? : 29.0TB Inode Count? ? ? ? ? : 3108974976 Free Inodes? ? ? ? ? : 3108881513 ---------------------------------------------------------------------------- -- Brick? ? ? ? ? ? ? ? : Brick nybaknode11.ex...