search for: getsunit

...the definition in X86Instr64bit.td, and an entry in X86InstrInfo.cpp. After commenting both out, compilation of a large application fails with: llc: ScheduleDAG.cpp:462: void llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion `Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()->NodeNum] && "Wrong topological sorting"' failed. bugpoint produced this minimal example which triggers the problem: define ccc void @ArgsFree() nounwind { entry: %0 = load void (i8*)** undef, align 4 call ccc void %0(i8* undef) nounwind unreachable } Any ideas?...

...X86Instr64bit.td, and an entry in X86InstrInfo.cpp. > After commenting both out, compilation of a large application fails with: > llc: ScheduleDAG.cpp:462: void > llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion > `Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()->NodeNum] && "Wrong > topological sorting"' failed. > bugpoint produced this minimal example which triggers the problem: > define ccc void @ArgsFree() nounwind { > entry: >   %0 = load void (i8*)** undef, align 4 >   call ccc void %0(i8* undef) nounwind...

...:-) I would like to instead ask another question: Why is I->isCtrl() used in code like // Iterate over chain dependencies only. for (SUnit::const_succ_iterator I = SUb->Succs.begin(), E = SUb->Succs.end(); I != E; ++I) if (I->isCtrl()) iterateChainSucc (AA, MFI, SUa, I->getSUnit(), ExitSU, Depth, Visited); ? I thought only chain edges are relevant, and would instead use if (J->getKind() == SDep::Order) I got strange edges, from memory accesses to normal operation instructions that do not touch memory, because also anti and output edges are followed. Best regards, J...

...d an entry in X86InstrInfo.cpp. > > After commenting both out, compilation of a large application fails with: > > llc: ScheduleDAG.cpp:462: void > > llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion > > `Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()->NodeNum] && "Wrong > > topological sorting"' failed. > > bugpoint produced this minimal example which triggers the problem: > > define ccc void @ArgsFree() nounwind { > > entry: > > %0 = load void (i8*)** undef, align 4 > > call cc...

...her question: > > Why is I->isCtrl() used in code like > > // Iterate over chain dependencies only. > for (SUnit::const_succ_iterator I = SUb->Succs.begin(), E = SUb->Succs.end(); > I != E; ++I) > if (I->isCtrl()) > iterateChainSucc (AA, MFI, SUa, I->getSUnit(), ExitSU, Depth, > Visited); > > ? > > I thought only chain edges are relevant, and would instead use if > (J->getKind() == SDep::Order) > > I got strange edges, from memory accesses to normal operation instructions that do not touch memory, because also anti and ou...

Hi, Can anyone help me to understand the ScheduleDAGInstrs::buildSchedGraph() method? I find the handling of AliasChain is disturbing since: 1. A new alias chain add deps to all possibly aliasing SUs, and then clears those lists. 2. When AliasChain is present, the addChainDependency() method is called, but the target hook areMemAccessesTriviallyDisjoint() called inside

Hi, I am attempting to modify LLVM to generate code for an architecture which is nearly identical to X86-64, but with a few minor differences. In particular, "call" must always have a register operand, and cannot have a memory operand. Any ideas on how I can express this rule? Thanks, - David -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Tue, Jun 8, 2010 at 2:05 PM, David Meyer <pdox at google.com> wrote: > Hi, > I am attempting to modify LLVM to generate code for an architecture which is > nearly identical to X86-64, but with a few minor differences. > In particular, "call" must always have a register operand, and cannot have a > memory operand. Any ideas on how I can express this rule? Just get

...g an assertion failure with respect to the DAG structure. .file "<stdin>" llc: ~/llvm/lib/CodeGen/ScheduleDAG.cpp:510: void llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion `Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()->NodeNum] && "Wrong topological sorting"' failed. 0 llc 0x000000000117ef3a llvm::sys::PrintStackTrace(_IO_FILE*) + 38 I am wondering if the modification made to the DAG is causing a problem, and can it be done at all? If I cannot do this, is there any other...

...State(); >> >> // End the current packet if needed. >> - if (isSoloInstruction(MI)) { >> + if (this->isSoloInstruction(MI)) { >> endPacket(MBB, MI); >> continue; >> } >> >> - SUnit *SUI = SchedulerImpl->getSUnit(MI); >> + // Ignore pseudo instructions. >> + if (this->ignorePseudoInstruction(MI, MBB)) >> + continue; >> + >> + SUnit *SUI = MIToSUnit[MI]; >> assert(SUI&& "Missing SUnit Info!"); >> >> // Ask DFA if...