<div>After removing CALL64m, the resulting DAG has a cycle that cannot be scheduled.</div><div><br></div><div>I've attached a PDF of the DAG before instruction selection (-view-isel-dags), and after instruction select (-view-sched-dags).</div>
<div><br></div><div>Notice how the flag/chain relationships between MOV64rm and CALL64r make it impossible to schedule.</div><div><br></div><div>Here's the code being compiled:</div><div><br></div><div><div><font class="Apple-style-span" face="'courier new', monospace">define ccc void @ArgsFree() nounwind {</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">entry:</font></div><div><font class="Apple-style-span" face="'courier new', monospace">  %0 = load void (i8*)** undef, align 4</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">  call ccc void %0(i8* undef) nounwind</font></div><div><font class="Apple-style-span" face="'courier new', monospace">  unreachable</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">}</font></div></div><div><br></div><div>Is this a bug in LLVM, or is there something else I need to do than just remove CALL64m?</div><div><br></div>
<div>- David</div><br><br><div class="gmail_quote">On Tue, Jun 8, 2010 at 5:09 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, Jun 8, 2010 at 4:20 PM, David Meyer <<a href="mailto:pdox@google.com">pdox@google.com</a>> wrote:<br>
> Hi Eli,<br>
> I have tried this, but the resulting tool-chain was broken.<br>
> There are only two references to "CALL64m": the definition in<br>
> X86Instr64bit.td, and an entry in X86InstrInfo.cpp.<br>
> After commenting both out, compilation of a large application fails with:<br>
> llc: ScheduleDAG.cpp:462: void<br>
> llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion<br>
> `Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()->NodeNum] && "Wrong<br>
> topological sorting"' failed.<br>
> bugpoint produced this minimal example which triggers the problem:<br>
> define ccc void @ArgsFree() nounwind {<br>
> entry:<br>
>   %0 = load void (i8*)** undef, align 4<br>
>   call ccc void %0(i8* undef) nounwind<br>
>   unreachable<br>
> }<br>
> Any ideas?<br>
> - David<br>
<br>
</div>I'm not really sure... possibly something is expecting to be able to<br>
fold the load into the call inst, and fails.<br>
<font color="#888888"><br>
-Eli<br>
</font><div><div></div><div class="h5"><br>
><br>
> On Tue, Jun 8, 2010 at 4:04 PM, Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>> wrote:<br>
>><br>
>> On Tue, Jun 8, 2010 at 2:05 PM, David Meyer <<a href="mailto:pdox@google.com">pdox@google.com</a>> wrote:<br>
>> > Hi,<br>
>> > I am attempting to modify LLVM to generate code for an architecture<br>
>> > which is<br>
>> > nearly identical to X86-64, but with a few minor differences.<br>
>> > In particular, "call" must always have a register operand, and cannot<br>
>> > have a<br>
>> > memory operand. Any ideas on how I can express this rule?<br>
>><br>
>> Just get rid of the pattern for matching the CALL64m instruction, or<br>
>> make it require a target feature your target doesn't have.<br>
>><br>
>> -Eli<br>
><br>
><br>
</div></div></blockquote></div><br>