search for: scheduledagsdnod

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 (se...

...rything 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 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?...

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 >>>> ASSERT's in >>>> VC++'s vector[] implementation (when _HAS_ITERATOR_DEBUGGING is on). >>>> >>>> As a work-around, I commented ou...

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

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, VRBaseMap); [...] } TheInstrEmitter::EmitMachineNode does this: if (II.usesCustomInsertionH...

...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 basically, it means that calling CreateNewSUnit with NULL will call NewSUnit with NULL and with result in NULL->isMachineOpcode() which would certainly trigger a segfault. Now I...

...ver, assertion messages are static strings, and don't include any information about the particular object/value which caused the assertion. In a 'data oriented' system like llvm, this makes it really difficult to pinpoint which node is actually triggering the assertion. For example, in ScheduleDAGSDNodesEmit.cpp (lib/CodeGen/SelectionDAG/), in the ScheduleDAGSDNodes::AddOperand method, there is the following assert: assert(Op.getValueType() !=MVT::Other && Op.getValueType() != MVT::Flag && "Chain and flag operands should occur at end of operand list!"); In order to und...

...erator 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:603 ScheduleDAGSDNodes::Run:36 ScheduleDAG::Run:61 ScheduleDAGRRList::Schedule::185 ScheduleDAGRRList::ListScheduleBottomUp:736 RegReductionPriorityQueue<bu_ls_rr_sort>::pop:1061 <-- exception here I haven't reported this as a bug because first I want to find out that in LLVM's usage of the std::prior...

...1_l = external global i1 @i1_s = external global i1 define void @i1_ls() nounwind { %tmp = load i1* @i1_l store i1 %tmp, i1* @i1_s ret void } Instruction selection works correctly, but the scheduling step fails with "Register class of operand and regclass of use don't agree!" in ScheduleDAGSDNodes::AddOperand. The selected DAG contains: (LOAD32p_8z (LOAD32imm (tglobaladdr "i1_l"))) LOAD32imm produces a GR-class vreg, and LOAD32p_8z expects a P-class vreg, hence the error. But P is a subclass of GR, so if the vreg class were changed to P everything would work. The solution...

...are static strings, and don't include any > information about the particular object/value which caused the > assertion. In a 'data oriented' system like llvm, this makes it really > difficult to pinpoint which node is actually triggering the assertion. > > For example, in ScheduleDAGSDNodesEmit.cpp > (lib/CodeGen/SelectionDAG/), in the ScheduleDAGSDNodes::AddOperand > method, there is the following assert: The typical idiom we use for this are things like: Value::~Value() { #ifndef NDEBUG // Only in -g mode... // Check to make sure that there are no uses of this valu...

...e 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:603 > ScheduleDAGSDNodes::Run:36 > ScheduleDAG::Run:61 > ScheduleDAGRRList::Schedule::185 > ScheduleDAGRRList::ListScheduleBottomUp:736 > RegReductionPriorityQueue<bu_ls_rr_sort>::pop:1061 <-- exception here > > I haven’t reported this as a bug because first I want to find out that in LLVM’s...

...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:603 >> ScheduleDAGSDNodes::Run:36 >> ScheduleDAG::Run:61 >> ScheduleDAGRRList::Schedule::185 >> ScheduleDAGRRList::ListScheduleBottomUp:736 >> RegReductionPriorityQueue<bu_ls_rr_sort>::pop:1061 <-- exception here >> >> I haven’t reported this as a bug because first I want to...

...ion selection is complete. I could do this in my InstructionSelect() as a first fix, but I think I would have to do something more clever eventually. I think a few tricks when creating vregs would go a long way: 1. If the def regclass is a subset of the operand regclass, there is no problem. ScheduleDAGSDNodes::AddOperand should simply allow this case. 2. If there is a regclass contained in the def regclass and all the operand regclasses, change the vreg regclass to the intersection. This could be a bad idea if there are many uses with different regclasses. 3. If def and operand regclasse...

...this in my > InstructionSelect() as a first fix, but I think I would have to do > something more clever eventually. > > I think a few tricks when creating vregs would go a long way: > > 1. If the def regclass is a subset of the operand regclass, there is > no > problem. ScheduleDAGSDNodes::AddOperand should simply allow this > case. > > 2. If there is a regclass contained in the def regclass and all the > operand regclasses, change the vreg regclass to the intersection. > This could be a bad idea if there are many uses with different > regclasses. > &g...

On Aug 27, 2010, at 11:53 AMPDT, Yuri wrote: > On 08/27/2010 11:32, Yuri wrote: >> As I understand only one of TCRETURNri64 and RET should be created. >> I have sources of rev.112200. >> >> Here is the stack when TCRETURNri64 instruction is created: >> #1 0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr >> (this=0x30eb000, TID=@0x803a78940,

...i1 > > define void @i1_ls() nounwind { > %tmp = load i1* @i1_l > store i1 %tmp, i1* @i1_s > ret void > } > > Instruction selection works correctly, but the scheduling step fails > with "Register class of operand and regclass of use don't agree!" in > ScheduleDAGSDNodes::AddOperand. The selected DAG contains: > > (LOAD32p_8z (LOAD32imm (tglobaladdr "i1_l"))) > > LOAD32imm produces a GR-class vreg, and LOAD32p_8z expects a P-class > vreg, hence the error. But P is a subclass of GR, so if the vreg class > were changed to P everything...

...aseMap=@0x7fffffff8050) at /tmp/llvm-svn/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:671 #4 0x00000008031f6bdf in llvm::InstrEmitter::EmitNode (this=0x7fffffff7f80, Node=0x4b6c510, IsClone=false, IsCloned=false, VRBaseMap=@0x7fffffff8050) at InstrEmitter.h:118 #5 0x00000008031f5781 in llvm::ScheduleDAGSDNodes::EmitSchedule (this=0x4b68400) at /tmp/llvm-svn/llvm/lib/CodeGen/SelectionDAG/ScheduleDAGSDNodes.cpp:602 #6 0x0000000803275459 in llvm::SelectionDAGISel::CodeGenAndEmitDAG (this=0x45174d0) at /tmp/llvm-svn/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:547 #7 0x00000008032740fc in llvm:...

...3 - Fixed old typo in ScalarEvolution, that caused wrong SCEVs zext operation. Owen Anderson: r200201 - Fix for PR18102. r200202 - Additional fix for 200201: due to dependence on bitwidth test was moved to X86 directory. r200705 - Expand vector bswap in LegalizeVectorOps r205738 - Put a limit on ScheduleDAGSDNodes::ClusterNeighboringLoads to avoid blowing up compile time. Evan Cheng: r200028 - InstCombine: Don't try to use aggregate elements of ConstantExprs. r199351 - BasicAA: We need to check both access sizes when comparing a gep and an r198290 - BasicAA: Fix value equality and phi cycles r198400...

...and don't include any >> information about the particular object/value which caused the >> assertion. In a 'data oriented' system like llvm, this makes it really >> difficult to pinpoint which node is actually triggering the assertion. >> >> For example, in ScheduleDAGSDNodesEmit.cpp >> (lib/CodeGen/SelectionDAG/), in the ScheduleDAGSDNodes::AddOperand >> method, there is the following assert: > > The typical idiom we use for this are things like: > > Value::~Value() { > #ifndef NDEBUG      // Only in -g mode... >   // Check to make sure...