similar to: [LLVMdev] Win32 JIT issue + bug in ScheduleDAGSNodes.h?

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

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

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

Bill Wendling wrote: > 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

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

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

Oh yes you're right, I missed that :) But the point still hold. Amaury Pouly 2010/8/8 Eugene Toder <eltoder at gmail.com> > > Not only this code does not compile with NDEBUG set > > I may be missing something, but why does it not compile with -DNDEBUG? > assert() macro expands to noop when NDEBUG is set. > > Eugene > > On Sun, Aug 8, 2010 at 2:19 PM, Amaury

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

> Not only this code does not compile with NDEBUG set I may be missing something, but why does it not compile with -DNDEBUG? assert() macro expands to noop when 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

>> While testing my compiler on win32 in JIT mode, I ran into a couple of >> issues: >> >> 1. I linked the compiler with the lib files resulting from the cmake >> created VS.NET build. While everything built just fine, the >> ExecutionEngine::create call always returned NULL. The fix was to also >> link with JIT.obj (thanks aKor for pointing me in the

srs <skaflotten at gmail.com> writes: >>> While testing my compiler on win32 in JIT mode, I ran into a couple of >>> issues: >>> >>> 1. I linked the compiler with the lib files resulting from the cmake >>> created VS.NET build. While everything built just fine, the >>> ExecutionEngine::create call always returned NULL. The fix was to

srs <skaflotten at gmail.com> writes: > While testing my compiler on win32 in JIT mode, I ran into a couple of > issues: > > 1. I linked the compiler with the lib files resulting from the cmake > created VS.NET build. While everything built just fine, the > ExecutionEngine::create call always returned NULL. The fix was to also > link with JIT.obj (thanks aKor for

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

Óscar Fuentes wrote: > srs <skaflotten at gmail.com> writes: > > >>>> While testing my compiler on win32 in JIT mode, I ran into a couple of >>>> issues: >>>> >>>> 1. I linked the compiler with the lib files resulting from the cmake >>>> created VS.NET build. While everything built just fine, the >>>>

Andy, 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

Hi Andy, The thing is that I was trying to build a sched graph in other places than these two standard scheduling passes. For instance, in pre-emit. I would like to reschedule a basic block on my vliw target just before assembly emission. I tried to add SUnits for hazards in an experiment, but this gave very weird errors... even while allocating extra space in SUnits vector. For some function, I

Is there any specific documentation on this? Is there a point of contact for this file that I might bug? So I have an instruction that needs noops inserted and it appears that the noops are being inserted in the EmitSchedule function of the PostRAScheduler. From the loop in EmitSchedule it looks like it's inserting noops whenever SUnit is NULL. I don't see anything in the DAG that appears

I am tracking down a tricky bug involving select/CMOV and scheduling. In my test, I have a float select that has to be implemented with a diamond CFG by the scheduler. The high level ScheduleDAGSDNodes::EmitSchedule does this: for (unsigned i = 0, e = Sequence.size(); i != e; i++) { [...] Emitter.EmitNode(SU->getNode(), SU->OrigNode != SU, SU->isCloned,

On Oct 16, 2012, at 1:43 PM, Sergei Larin <slarin at codeaurora.org> wrote: > > 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

Hi, I have an assert firing due to PickNodeToScheduleBottomUp(): 1. having a CallResource in use pushing an interference of current SUnit. 2. having no more SUnits in the AvailableQueue 3. The only interference being the SUnit that just failed due to a Call Resource. 4. An attempt to duplicate this node which has the 'Call Resource' as a physical register. Thus the call