search for: rawfrm

...d try something like the following.. Index: lib/Target/X86/X86InstrSystem.td =================================================================== --- lib/Target/X86/X86InstrSystem.td (revision 161828) +++ lib/Target/X86/X86InstrSystem.td (working copy) @@ -445,6 +445,7 @@ def XSTORE : I<0xc0, RawFrm, (outs), (ins), "xstore", []>, A7; def : InstAlias<"xstorerng", (XSTORE)>; +def : InstAlias<"xstore-rng", (XSTORE)>; let Defs = [RSI, RDI], Uses = [RBX, RDX, RSI, RDI] in { def XCRYPTECB : I<0xc8, RawFrm, (outs), (ins), "xcryptecb",...

On Jan 16, 2013, at 10:07 AM, Brad Smith <brad at comstyle.com> wrote: > I was wondering if someone with more familiarity with MC > on X86 could consider looking into adding support for > the hyphenated versions of the VIA Padlock instructions? Take a look at llvm/lib/Target/X86InstrSystem.td perhaps. -- Stephen Checkoway

I was wondering if someone with more familiarity with MC on X86 could consider looking into adding support for the hyphenated versions of the VIA Padlock instructions? If anyone is up for it there are details within these two bug reports.. http://www.llvm.org/bugs/show_bug.cgi?id=8556 http://www.llvm.org/bugs/show_bug.cgi?id=10266 -- This message has been scanned for viruses and dangerous

...printers want % signs. > > The GAS intel code generator generates percents, look at the X86InstrInfo.td > file it is full of them. Ah, I see what you're talking about. Please feel free to remove all of those from the Intel format. For example, change this: def IN8rr : I<0xEC, RawFrm, (ops), "in{b} {%dx, %al|%AL, %DX}">, Imp<[DX], [AL]>; to: def IN8rr : I<0xEC, RawFrm, (ops), "in{b} {%dx, %al|AL, DX}">, Imp<[DX], [AL]>; For register allocatable values, changing printOp in the X86IntelAsmPrinter shou...

...;> The GAS intel code generator generates percents, look at the >> X86InstrInfo.td file it is full of them. > > Ah, I see what you're talking about. Please feel free to remove all of > those from the Intel format. For example, change this: > > def IN8rr : I<0xEC, RawFrm, (ops), > "in{b} {%dx, %al|%AL, %DX}">, Imp<[DX], [AL]>; > > to: > > def IN8rr : I<0xEC, RawFrm, (ops), > "in{b} {%dx, %al|AL, DX}">, Imp<[DX], [AL]>; > > For register allocatable values, changing prin...

>>> You shouldn't have to add new classes to the .td file, just modify >>> printOp for your asmprinters. >> >> I dont think printOp is virtual and therefore cannot be overriden ? > > Why does it need to be virtual? No 'intel' printers want % signs. The GAS intel code generator generates percents, look at the X86InstrInfo.td file it is full of

...cks for binary/unary/control/etc instructions. Ideally, I'd like to write this in .td file: class Binary : .... def add : Binary<....>; def sub : Binary<....>; It seems that X86 does something like this. The .td. file define: def Pseudo : Format<0>; def RawFrm : Format<1>; and there are parallel definitions in X86InstrInfo.h: Pseudo = 0, RawFrm = 1, Those definitions are used in codegen, and and TableGen somehow passes the instruction format information to X86GenInstInfo.inc -- specifically, it encodes it in the TSF...

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:

...n() { int a, b, c; a=1;b=2; c = int_x86_max_qb(a, b); } When I use clang to compile，there is a warning:implicit declaration of function 'int_x86_max_qb' is invalid in C99 [-Wimplicit-function-declaration]. So I add the definition in src/lib/Target/X86/X86InstrInfo.td def MAX_QB : I<0xff,RawFrm, (outs GR32:$Rd), (ins GR32:$src1,GR32:$src2),"max_qb \t $Rd $src1 $src2", []>, OpSize32; But it doesn't work.What should I do to make it correct? please tell me.Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pip...

...: Which file in the llvm/lib/Target/X86 folder describes how the bits in the EFLAGS register are modified by the x86 instructions? For example, in the "X86InstrInfo.td" file, lines 2134-2135, it says: let SchedRW = [WriteALU], Defs = [EFLAGS], Uses = [EFLAGS] in { def CLC : I<0xF8, RawFrm, (outs), (ins), "clc", []>; So it says the Defs of CLC is EFLAGS, but actually the CLC instruction only clears the "CF" flag in the EFLAGS register and has nothing to do with the other bits of EFLAGS. So which files in this folder describes the fact that CLC only modifies...

Hi Tim, Tim Northover-2 wrote > The code used for DIV is around X86ISelDAGToDAG.cpp:2415, but from a > glance the key points seem to be: > 1. use the second result of getCopyToReg (i.e. SDValue(setIdNode, 1)) > in the RDMSR node. > 2. Give your RDMSR node type MVT::Glue instead of MVT::Other I tried doing what you said, and the DAG looks like how I think it supposed to look like

I'm trying to add intrinsics for the Signal Processing Engine (FPU/vector unit) on some PowerPC cores, but running into a problem. Some of the instructions take an immediate operand, but I can't figure out how to make the intrinsic use an immediate, it just wants to load a register as an argument to the function. Is there any way in the .td file to describe the intrinsic as taking an

...t; instructions. Ideally, I'd like to write this in .td file: > class Binary : .... > def add : Binary<....>; > def sub : Binary<....>; > > It seems that X86 does something like this. The .td. file define: > > def Pseudo : Format<0>; def RawFrm : Format<1>; > > and there are parallel definitions in X86InstrInfo.h: > > Pseudo = 0, > RawFrm = 1, Exactly. > Those definitions are used in codegen, and and TableGen somehow passes the > instruction format information to X86GenInstInfo.inc...

Vladimir Prus wrote: > On my target, the multiplication can involve all general purpose registers, > but there's are still some restrictions: the first and the second operand > as well as the result must be in different registers, and neither register > can be gr7. How can I enforce this restriction on the register allocator? And the other side of the question is now to inform

On Tue, 12 Jul 2005, Aaron Gray wrote: >>> X86InstrInfo.td file it is full of them. >> >> Ah, I see what you're talking about. Please feel free to remove all of >> those from the Intel format. For example, change this: >> >> def IN8rr : I<0xEC, RawFrm, (ops), >> "in{b} {%dx, %al|%AL, %DX}">, Imp<[DX], [AL]>; >> >> to: >> >> def IN8rr : I<0xEC, RawFrm, (ops), >> "in{b} {%dx, %al|AL, DX}">, Imp<[DX], [AL]>; >> >> For registe...

Hi Jun, I'm not sure how to fix this yet, but this looks incorrectly defined in lib/Target/X86/X86InstrInfo.td: def MOV32o32a : Ii32 <0xA1, RawFrm, (outs), (ins offset32:$src), "mov{l}\t{$src, %eax|eax, $src}", [], IIC_MOV_MEM>, Requires<[In32BitMode]>; This instruction can be REX-prefixed for a 64-bit move, and that also doesn't appear to be defined anywhere. I would file a...

Hi, With objdump, i have this (Intel syntax) 64 a1 00 00 00 00 mov eax,fs:0x0 However, if I pass above string to llvm-mc, I would have: $ echo "0x64 0xa1 0x00 0x00 0x00 0x00"|./Release+Asserts/bin/llvm-mc -disassemble -arch=x86 --output-asm-variant=1 .text mov eax, dword ptr [0] You can see a big difference. This is on the latest code. Any idea how to

On Thu, Nov 28, 2013 at 1:03 AM, Kay Tiong Khoo <kkhoo at perfwizard.com>wrote: > Hi Jun, > > I'm not sure how to fix this yet, but this looks incorrectly defined in > lib/Target/X86/X86InstrInfo.td: > > def MOV32o32a : Ii32 <0xA1, RawFrm, (outs), (ins offset32:$src), > "mov{l}\t{$src, %eax|eax, $src}", [], IIC_MOV_MEM>, > Requires<[In32BitMode]>; > > This instruction can be REX-prefixed for a 64-bit move, and that also > doesn't appear to be defined an...

On my target, the multiplication can involve all general purpose registers, but there's are still some restrictions: the first and the second operand as well as the result must be in different registers, and neither register can be gr7. How can I enforce this restriction on the register allocator? - Volodya

On Tue, 2014-01-14 at 22:59 -0800, Craig Topper wrote: > I started trying to fix this tonight but it's pretty nasty to fix. > I'll try to make another go at it later this week. Much of it seems fixed already; what's left to fix? The segment prefix override? Does that mean we get to fix disassembly of '0x65 0xa4' while we're at it? (Although we can't even