search for: scheduledagsnod

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

Óscar Fuentes wrote: > srs <skaflotten at gmail.com> writes: > > >>>>> Try adding this to the link command of your executable: >>>>> >>>>> /INCLUDE:_X86TargetMachineModule >>>>> >>>>> I should document this somehow. >>>>> >>>>> >>>> Yeah, this is

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

2008/12/30 srs <skaflotten at gmail.com> > Ó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 >

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

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

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

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

Hi all, 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 right direction). I would have thought that linking

srs <skaflotten at gmail.com> writes: >>>> Try adding this to the link command of your executable: >>>> >>>> /INCLUDE:_X86TargetMachineModule >>>> >>>> I should document this somehow. >>>> >>> Yeah, this is necessary, but not sufficient. I also had to link with >>> ExecutionEngineBindings.obj

Ó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 >>>>

...t >. 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 thus allocate a new one. This gives code this: ScheduleDAGSNodes.cpp: #ifndef NDEBUG const SUnit *Addr = 0; if (!SUnits.empty()) Addr = &SUnits[0]; #endif SUnits.push_back(SUnit(N, (unsigned)SUnits.size())); assert((Addr == 0 || Addr == &SUnits[0]) && Not only this code does not compile with NDEBUG set but it could trigger an exte...

...ter 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 > > thus allocate a new one. This gives code this: > > > > ScheduleDAGSNodes.cpp: > > > > #ifndef NDEBUG > > const SUnit *Addr = 0; > > if (!SUnits.empty()) > > Addr = &SUnits[0]; > > #endif > > SUnits.push_back(SUnit(N, (unsigned)SUnits.size())); > > assert((Addr == 0 || Addr == &SUnits[0]) && &g...

...lem 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 > thus allocate a new one. This gives code this: > > ScheduleDAGSNodes.cpp: > > #ifndef NDEBUG >   const SUnit *Addr = 0; >   if (!SUnits.empty()) >     Addr = &SUnits[0]; > #endif >   SUnits.push_back(SUnit(N, (unsigned)SUnits.size())); >   assert((Addr == 0 || Addr == &SUnits[0]) && > > Not only this code does not comp...

...gt; 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 >> > thus allocate a new one. This gives code this: >> > >> > ScheduleDAGSNodes.cpp: >> > >> > #ifndef NDEBUG >> >   const SUnit *Addr = 0; >> >   if (!SUnits.empty()) >> >     Addr = &SUnits[0]; >> > #endif >> >   SUnits.push_back(SUnit(N, (unsigned)SUnits.size())); >> >   assert((Addr == 0 || Addr...

...ister "r1", it's same to the 5th and 6th instruction. That's to say, the six instructions use the same register. However, for 3th and 4th instructions, they should be allocated different register from the second instruction. So, I insert a breakpoint in BuildSchedGraph function in ScheduleDAGSNodes.cpp to debug the source code. Then I get schedule graph of this basic block: Like the above graph, Pre-RA-sched(ScheduleRRList.cpp) is unable to insert the 3th SDNode(load2 instruction) between the first SDNode(load1 Instruction) and the second store1 SDNode. Then in the register allocation step...

...'s no ByPass info out there. are you sure this reflects the real R4xxx/R5xxx processors. why IILoad uses funcition unit ALU? InstrItinData<IILoad , [InstrStage<3, [ALU]>]> for my previous question, I have new input after reading the code. pre-RA-sched is derived from ScheduleDAGSNodes, but post-RA-sched and mi-sched are both derived from ScheduleDAGInstrs.that means pre-RA-sched schedules SDNodes. post-RA-sched schedules MIs. from -debug-pass=Structure, we can see that the order is "mi-sched"==> RegisterAllocation==>post-RA TD. Simple Register Coalescin...

Akira, Thanks you for response. I understand Post-RA schedule make uses of scoreboardHazardRecognizer. But I found mips codes are good enough by default. basically, I can not easily eyeball any bubbles. I don't understand how they can do that without post-RA-sched. pre-ra-scheduler eg. (SelectionDAG/ScheduleDAGRRList.cpp) has little information and they can only schedule node in topology

...(ALU and IMULDIV) are defined and used in this .td file, but this would be incorrect if load instructions did not have any resource conflicts with other ALU instructions on your target. > > for my previous question, I have new input after reading the code. > pre-RA-sched is derived from ScheduleDAGSNodes, but post-RA-sched and > mi-sched are both derived from ScheduleDAGInstrs.that means pre-RA-sched > schedules SDNodes. post-RA-sched schedules MIs. > > from -debug-pass=Structure, we can see that the order is "mi-sched"==> > RegisterAllocation==>post-RA TD. > &gt...