search for: call64m

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...

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...

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->...

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:

...de 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

I'm iterating over MCInsts and I'd like to examine particular instructions. For example, I'd like to look at all x86 CALL64m instructions. I may be missing something, but it seems like my only option is to use MCInstPrinter::getOpcodeName and compare strings. (Of course, I could iterate through the opcodes and build up a table of the ones I'm interested in to avoid string comparisons.) Register mappings to names see...

...public.) PS Sorry for the duplicate, Stephen. I forgot to CC the list. On Oct 28, 2013 12:03 PM, "Stephen Checkoway" <s at pahtak.org> wrote: > I'm iterating over MCInsts and I'd like to examine particular > instructions. For example, I'd like to look at all x86 CALL64m > instructions. I may be missing something, but it seems like my only option > is to use MCInstPrinter::getOpcodeName and compare strings. (Of course, I > could iterate through the opcodes and build up a table of the ones I'm > interested in to avoid string comparisons.) > > R...

...Info.inc and X86GenInstrInfo.inc would be very handy. Steve > > > On Oct 28, 2013 12:03 PM, "Stephen Checkoway" <s at pahtak.org> wrote: > I'm iterating over MCInsts and I'd like to examine particular instructions. For example, I'd like to look at all x86 CALL64m instructions. I may be missing something, but it seems like my only option is to use MCInstPrinter::getOpcodeName and compare strings. (Of course, I could iterate through the opcodes and build up a table of the ones I'm interested in to avoid string comparisons.) > > Register mappings to...

...ld be very handy. > > Steve > > > > > > > On Oct 28, 2013 12:03 PM, "Stephen Checkoway" <s at pahtak.org> wrote: > > I'm iterating over MCInsts and I'd like to examine particular > instructions. For example, I'd like to look at all x86 CALL64m > instructions. I may be missing something, but it seems like my only option > is to use MCInstPrinter::getOpcodeName and compare strings. (Of course, I > could iterate through the opcodes and build up a table of the ones I'm > interested in to avoid string comparisons.) > > &...