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
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/f6456814/attachment.html>
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? > - DavidI'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 > >
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>