llvm dev - Jun 2010 - [LLVMdev] Always unfold memory operand

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:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100608/e845d7ff/attachment.html>

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

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>