similar to: [LLVMdev] ISel using an operand as both source and destination

I see in the x86 InstInfo.td the following for the INC instructions: def INC8r : I<0xFE, MRM0r, (ops GR8 :$dst, GR8 :$src), "inc{b} $dst", [(set GR8:$dst, (add GR8:$src, 1))]>; Which seem to have the same restriction that I'm trying to implement, but I don't understand how this ensures that $src and $dst are the same register. -- Christopher Lamb

On Thu, 1 Mar 2007, Christopher Lamb wrote: > I see in the x86 InstInfo.td the following for the INC instructions: > > def INC8r : I<0xFE, MRM0r, (ops GR8 :$dst, GR8 :$src), "inc{b} $dst", > [(set GR8:$dst, (add GR8:$src, 1))]>; > > Which seem to have the same restriction that I'm trying to implement, > but I don't understand how this

I have a question: In the pattern below from X86 def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), "inc{b}\tdst", [(set GR8:$dst, (add GR8:$src, 1))]>; Since we are emitting only "inc $dst", What makes sure that the $src and $dst are same register? - Sanjiv

sanjiv gupta wrote: > I have a question: > In the pattern below from X86 > > def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), > "inc{b}\tdst", > [(set GR8:$dst, (add GR8:$src, 1))]>; > > Since we are emitting only "inc $dst", > What makes sure that the $src and $dst are same register? > > - Sanjiv It's enclosed

On Tue, 2008-09-23 at 13:33 +0100, Richard Osborne wrote: > sanjiv gupta wrote: > > I have a question: > > In the pattern below from X86 > > > > def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), > > "inc{b}\tdst", > > [(set GR8:$dst, (add GR8:$src, 1))]>; > > > > Since we are emitting only "inc $dst",

I found that LLVM were using Binutils to assemble the Assembly Code to the Machine Code, so I have a question, why LLVM don't direct generate the machine code? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080923/b7e42591/attachment.html>

On Sep 22, 2008, at 13:36, 罗勇刚 wrote: > I found that LLVM were using Binutils to assemble the Assembly Code > to the Machine Code, so I have a question, why LLVM don't direct > generate the machine code? There was a protracted and rather uninteresting discussion of this matter on this list some months ago. I'll summarize the outcome of that thread briefly: LLVM does

Hi, Is it possible to define an Instruction with tablegen that reads and writes the same register? For example, an increment instruction that reads a value from a register, adds one to it and then writes the result back to the same register. Thanks, Tom

sanjiv gupta wrote: > On Tue, 2008-09-23 at 13:33 +0100, Richard Osborne wrote: > >> sanjiv gupta wrote: >> >>> I have a question: >>> In the pattern below from X86 >>> >>> def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), >>> "inc{b}\tdst", >>> [(set GR8:$dst, (add GR8:$src, 1))]>;

Hi, I am trying to do a backend to a very simple microcontroller. I have some questions. 1) I have instruction which do "r1 <- r1 op r2", from what I have ssen I must declare them like: let isTwoAddress = 1 in def ADD : FopRR< 0b01010, (outs CPURegs:$sX), (ins CPURegs:$isX, CPURegs:$sY), "ADD $sX, $sY"), [(set

Hi Chris, Thanks a lot for your answer! Chris Lattner wrote: >> 1. Why does X86 instruction set description provide different >> descriptions for the same instructions, which differ only in the size >> of operands? >> E.g. >> >> def MOV8rm : I<0x8A, MRMSrcMem, (ops GR8 :$dst, i8mem :$src), >> "mov{b} {$src, $dst|$dst, $src}",

I thought I'd share a little bit of progress I made this weekend. I've gotten the first interesting test-case (a simple switch) through hyperblock-based DAGISel, and there's a pretty picture too! Each part of the switch is emitted directly into the DAG, rather than being deferred. This is the function: define i32 @foo(i32 %x, i32 %z) nounwind { entry: switch i32 %x,

Currently tablegen emits a rather surprising match code for the following case: Suppose we have a pattern that uses a ComplexPattern to match an operand. This pattern then appears as a child pattern in a different pattern. Pattern 1: (N1 ComplexPattern:OP) Pattern 0: (N0 (N1 ComplexPattern:OP)) The match code for ComplexPattern is passed in N1 in Pattern 1 and N0 in Pattern 0. This means

On Jan 1, 2008, at 9:29 PM, Evan Cheng wrote: > > On Dec 30, 2007, at 9:04 PM, Christopher Lamb wrote: > >> Currently tablegen emits a rather surprising match code for the >> following case: >> >> Suppose we have a pattern that uses a ComplexPattern to match an >> operand. This pattern then appears as a child pattern in a >> different pattern.

Can someone explain the Constraints system in X86*.td? For example: let Constraints = "$src1 = $dst" This replaces isTwoAddress (according to svn logs), which I gather is how two-address instructions used to be marked for X86. Except isTwoAddress is still used in X86InstInfo.td. So what gives? What do these two properties actually do?

Very nice! Why did you decide on hyperblock instead of SEME region and how are you forming the blocks? Evan On Apr 20, 2008, at 9:59 PM, Christopher Lamb wrote: > I thought I'd share a little bit of progress I made this weekend. > I've gotten the first interesting test-case (a simple switch) > through hyperblock-based DAGISel, and there's a pretty picture too! >

hi, at the moment, TEST instruction is defined with 0xf7 opcode, as demonstrated below. $ echo "0xf7 0xc0 0x00 0x00 0x00 0x22"|./Release+Asserts/bin/llvm-mc -disassemble -arch=x86 .section __TEXT,__text,regular,pure_instructions testl $570425344, %eax ## imm = 0x22000000 however, i cannot find anywhere this F7 opcode is defined in

On Dec 30, 2007, at 9:04 PM, Christopher Lamb wrote: > Currently tablegen emits a rather surprising match code for the > following case: > > Suppose we have a pattern that uses a ComplexPattern to match an > operand. This pattern then appears as a child pattern in a > different pattern. > Pattern 1: (N1 ComplexPattern:OP) > Pattern 0: (N0 (N1 ComplexPattern:OP)) >

On Feb 12, 2007, at 12:58 PM, Evan Cheng wrote: > > On Feb 12, 2007, at 1:41 AM, Christopher Lamb wrote: > >> >> selector refused to select certain ops (specifically stores) for some >> instructions when the operand type wasn't the first type for the >> register class. After some digging around I seem to have solved the >> problem by creating bitconvert

On Jun 17, 2008, at 1:36 PM, David Greene wrote: > Can someone explain the Constraints system in X86*.td? > > For example: > > let Constraints = "$src1 = $dst" > > This replaces isTwoAddress (according to svn logs), which I gather > is how > two-address instructions used to be marked for X86. You're right. This is the same as isTwoAddress, just more