[LLVMdev] Always unfold memory operand

[David Meyer]

After removing CALL64m, the resulting DAG has a cycle that cannot be
scheduled.

I've attached a PDF of the DAG before instruction selection
(-view-isel-dags), and after instruction select (-view-sched-dags).

Notice how the flag/chain relationships between MOV64rm and CALL64r make it
impossible to schedule.

Here's the code being compiled:

define ccc void @ArgsFree() nounwind {
entry:
  %0 = load void (i8*)** undef, align 4
  call ccc void %0(i8* undef) nounwind
  unreachable
}

Is this a bug in LLVM, or is there something else I need to do than just
remove CALL64m?

- David


On Tue, Jun 8, 2010 at 5:09 PM, Eli Friedman <eli.friedman at gmail.com> wrote:

> On Tue, Jun 8, 2010 at 4:20 PM, David Meyer <pdox at google.com> wrote:
> > Hi Eli,
> > I have tried this, but the resulting tool-chain was broken.
> > There are only two references to "CALL64m": 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?
> > - David
>
> I'm not really sure... possibly something is expecting to be able to
> fold the load into the call inst, and fails.
>
> -Eli
>
> >
> > On Tue, Jun 8, 2010 at 4:04 PM, Eli Friedman <eli.friedman at gmail.com>
> wrote:
> >>
> >> 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 rid of the pattern for matching the CALL64m instruction, or
> >> make it require a target feature your target doesn't have.
> >>
> >> -Eli
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100608/acc58195/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BeforeISEL.pdf
Type: application/pdf
Size: 6163 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100608/acc58195/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AfterISEL.pdf
Type: application/pdf
Size: 7067 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100608/acc58195/attachment-0001.pdf>