similar to: [LLVMdev] A question.

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

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 have some instructions that use a register as both an input and as the output. Is there a way to specify this constraint in the InstrInfo.td or will this have to be custom selected/lowered? Thanks -- Christopher Lamb christopher.lamb at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

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

Hello. I write backend for Z80 cpu and I have some trouble with lowering load/store nodes to different machine opcodes. Some target instructions work with specified registers (not all registers in RegisterClass). Often it's one or two registers. I don't understand how use ComplexPattern in this case. But if I don't use ComplexPattern I'll have other problems - not all

Hi, I am wondering how to specify the selection DAG patterns for instructions that use accumulator. For example multiply-accumulate instruction with one destination operand and two source operands: mac $dst, $src1, $src2 ;; $dst += $src1*$src2 Seems that it has a cycle in the pattern. So how do I specify it in the DAG? There are a few instructions in the ARM backend like this one, but the

Hi, This patch fixes outs/ins of MOV16mr instruction of X86. Thanks. diff --git a/lib/Target/X86/X86InstrInfo.td b/lib/Target/X86/X86InstrInfo.td index e9a0431..f5b2064 100644 --- a/lib/Target/X86/X86InstrInfo.td +++ b/lib/Target/X86/X86InstrInfo.td @@ -1412,7 +1412,7 @@ let SchedRW = [WriteStore] in { def MOV8mr : I<0x88, MRMDestMem, (outs), (ins i8mem :$dst, GR8 :$src),

On Jun 3, 2011, at 2:59 AM, Galanov, Sergey wrote: > Hi, Bill and Jakob. > > I don't quite understand. I am talking about CMOV_GR* instructions which are conservatively marked as clobbering EFLAGS in X86InstrCompiler.td. Doesn't that mean there cannot be any use of EFLAGS in subsequent instructions before it is defined by some other instruction? > > I also don't

Thanks for spelling it out, now I understand. On Jun 5, 2011, at 6:11 AM, Galanov, Sergey wrote: > Well, the point is CMOV_GR* are marked clobbering EFLAGS conservatively just in case they turn out to be lowered into a sequence containing XOR %reg,%reg which indeed clobbers EFLAGS. This means there might not be any instruction which actually uses this EFLAGS value. This actually looks like a

I am working on a project where we are integrating an existing pre-RA scheduler into LLVM and we are trying to match our peak register pressure values with the machine instruction schedulers values while using X86. I am finding some mismatches in test cases like the one attached. The registers "AH" and "AL" are live-out but not live-in and I don't see that they are defined

Well, the point is CMOV_GR* are marked clobbering EFLAGS conservatively just in case they turn out to be lowered into a sequence containing XOR %reg,%reg which indeed clobbers EFLAGS. This means there might not be any instruction which actually uses this EFLAGS value. For an example we can look no further than the actual test which has been disabled after the fix

Hi, I'm trying to implement a new backend for an embedded CISC processor. Therefore I thought that it makes sense to take X86 target as a basis, to save some time. But when I look into the X86InstrInfo.td, I have a very strong feeling that it is one of the most complex instruction set descriptions compared to other targets. I can imagine that this is due to the complexity of X86's

I am new to the LLVM backends, I am wondering how instruction selection is done in LLVM backends, I looked at the .td files in Target/X86, they all seem to be small and do not deal with common X86 instructions, i.e. mov, push, pop, etc. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

>I am assuming a 16-bit value will be stored in a pair of 8-bit > registers? One related question is how to make sure that the correct register pair is allocated to the16-bit quantity when using two 8-bit operations. In other words, how we can make sure that the 16-bit pointer is stored into [AH, AL] and not in [AH, BL] ? i.e. GR8 = [ AH, BH, AL, BL]; GR16 = [AX, BX] ; // AX, BX