summaryrefslogtreecommitdiffstats
path: root/llvm/test/MC/X86/intel-syntax.s
Commit message (Collapse)AuthorAgeFilesLines
* [X86][AsmParser] Ignore "short" even harder in Intel syntax ASM.David L. Jones2019-05-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | In Intel syntax, it's not uncommon to see a "short" modifier on Jcc conditional jumps, which indicates the offset should be a "short jump" (8-bit immediate offset from EIP, -128 to +127). This patch expands to all recognized Jcc condition codes, and removes the inline restriction. Clang already ignores "jmp short" in inline assembly. However, only "jmp" and a couple of Jcc are actually checked, and only inline (i.e., not when using the integrated assembler for asm sources). A quick search through asm-containing libraries at hand shows a pretty broad range of Jcc conditions spelled with "short." GAS ignores the "short" modifier, and instead uses an encoding based on the given immediate. MS inline seems to do the same, and I suspect MASM does, too. NASM will yield an error if presented with an out-of-range immediate value. Example of GCC 9.1 and MSVC v19.20, "jmp short" with offsets that do and do not fit within 8 bits: https://gcc.godbolt.org/z/aFZmjY Differential Revision: https://reviews.llvm.org/D61990 llvm-svn: 360954
* [X86] Print all register forms of x87 fadd/fsub/fdiv/fmul as having two ↵Craig Topper2019-02-041-42/+42
| | | | | | | | | | arguments where on is %st. All of these instructions consume one encoded register and the other register is %st. They either write the result to %st or the encoded register. Previously we printed both arguments when the encoded register was written. And we printed one argument when the result was written to %st. For the stack popping forms the encoded register is always the destination and we didn't print both operands. This was inconsistent with gcc and objdump and just makes the output assembly code harder to read. This patch changes things to always print both operands making us consistent with gcc and objdump. The parser should still be able to handle the single register forms just as it did before. This also matches the GNU assembler behavior. llvm-svn: 353061
* [X86] Print %st(0) as %st when its implicit to the instruction. Continue ↵Craig Topper2019-02-041-6/+6
| | | | | | | | printing it as %st(0) when its encoded in the instruction. This is a step back from the change I made in r352985. This appears to be more consistent with gcc and objdump behavior. llvm-svn: 353015
* Revert r352985 "[X86] Print %st(0) as %st to match what gcc inline asm uses ↵Craig Topper2019-02-041-33/+33
| | | | | | | | | | as the clobber name to make MS inline asm work correctly" Looking into gcc and objdump behavior more this was overly aggressive. If the register is encoded in the instruction we should print %st(0), if its implicit we should print %st. I'll be making a more directed change in a future patch. llvm-svn: 353013
* [X86] Print %st(0) as %st to match what gcc inline asm uses as the clobber ↵Craig Topper2019-02-031-33/+33
| | | | | | | | | | | | | | | | | | | name to make MS inline asm work correctly Summary: When calculating clobbers for MS style inline assembly we fail if the asm clobbers stack top because we print st(0) and try to pass it through the gcc register name check. This was found with when I attempted to make a emms/femms clobber all ST registers. If you use emms/femms in MS inline asm we would try to use st(0) as the clobber name but clang would think that wasn't a valid clobber name. This also matches what objdump disassembly prints. It's also what is printed by gcc -S. Reviewers: RKSimon, rnk, efriedma, spatel, andreadb, lebedev.ri Reviewed By: rnk Subscribers: eraman, gbedwell, lebedev.ri, llvm-commits Differential Revision: https://reviews.llvm.org/D57621 llvm-svn: 352985
* [X86] Allow base and index for gather instructions to appear in other order ↵Craig Topper2018-06-251-0/+5
| | | | | | for Intel syntax. llvm-svn: 335500
* [X86][AsmParser] In Intel syntax make sure we support ESP/RSP being the ↵Craig Topper2018-06-221-0/+8
| | | | | | | | | | second register in memory expressions like [EAX+ESP]. By default, the second register gets assigned to the index register slot. But ESP can't be an index register so we need to swap it with the other register. There's still a slight bug that we allow [EAX+ESP*1]. The existence of the multiply even though its with 1 should force ESP to the index register and trigger an error, but it doesn't currently. llvm-svn: 335394
* [X86] Don't accept (%si,%bp) 16-bit address expressions.Craig Topper2018-06-221-0/+1
| | | | | | | | | | The second register is the index register and should only be %si or %di if used with a base register. And in that case the base register should be %bp or %bx. This makes us compatible with gas. We do still need to support both orders with Intel syntax which uses [bp+si] and [si+bp] llvm-svn: 335384
* [X86] Remove 'opaque ptr' from the intel syntax parser and printer.Craig Topper2018-05-011-2/+2
| | | | | | | | Previously for instructions like fxsave we would print "opaque ptr" as part of the memory operand. Now we print nothing. We also no longer accept "opaque ptr" in the parser. We still accept any size to be specified for these instructions, but we may want to consider only parsing when no explicit size is specified. This what gas does. llvm-svn: 331243
* [X86] Add a Requires<[In64BitMode]> to FARJMP64Craig Topper2018-04-301-1/+1
| | | | | | Otherwise we can try to assemble it in 32-bit mode and throw an assert in the encoder. llvm-svn: 331161
* [X86] Remove support for accepting 'fnstsw %eax' and 'fnstsw %al'.Craig Topper2018-04-301-4/+0
| | | | | | I assume this was done because gas accepted it at one point, but current versions of gas don't. llvm-svn: 331154
* [X86] Make 64-bit sysret/sysexit not ambiguous in Intel assembly syntax.Craig Topper2018-04-291-0/+9
| | | | | | This also makes it default to the 32-bit non REX.W version in 64-bit mode. This seems to be more consistent with gas. llvm-svn: 331149
* [X86] Change 32 and 64 bit versions of LSL instruction have a 16-bit memory ↵Craig Topper2018-02-151-0/+8
| | | | | | | | operand. This matches the Intel and AMD documentation and is consistent with the LAR instruction. llvm-svn: 325197
* Fix incorrect operand sizes for some MMX instructions: punpcklwd, punpcklbw ↵Andrew V. Tischenko2017-12-291-0/+8
| | | | | | | | and punpckldq. Differential Revision: https://reviews.llvm.org/D41595 llvm-svn: 321549
* [X86] Change register&memory TEST instructions from MRMSrcMem to MRMDstMemCraig Topper2017-10-011-8/+8
| | | | | | | | | | | | | | | | | | | Summary: Intel documentation shows the memory operand as the first operand. But we currently treat it as the second operand. Conceptually the order doesn't matter since it doesn't write memory. We have aliases to parse with the operands in either order and the isel matching is commutable. For the register&register form order does matter for the assembly parser. PR22995 was previously filed and fixed by changing the register&register form from MRMSrcReg to MRMDestReg to match gas. Ideally the memory form should match by using MRMDestMem. I believe this supercedes D38025 which was trying to switch the register&register form back to pre-PR22995. Reviewers: aymanmus, RKSimon, zvi Reviewed By: aymanmus Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38120 llvm-svn: 314639
* [x86][AsmParser] Allow some more MS size directivesCoby Tayree2017-09-281-0/+7
| | | | | | | MS allows the following size directives: float/double and long as synonymous to dword/qword and dword, respectively. Differential Revision: https://reviews.llvm.org/D37190 llvm-svn: 314410
* [X86AsmParser] Refactoring, (almost) NFC.Coby Tayree2017-08-241-9/+19
| | | | | | | | | | Some refactoring to X86AsmParser, mostly regarding the way rewrites are conducted. Mainly, we try to concentrate all the rewrite effort under one hood, so it'll hopefully be less of a mess and easier to maintain and understand. naturally, some frontend tests were affected: D36794 Differential Revision: https://reviews.llvm.org/D36793 llvm-svn: 311639
* [X86][Asm]Allow far jmp/call to be picked when using explicit FWORD size ↵Coby Tayree2017-08-091-0/+9
| | | | | | | | | | | specifier Currently, far jmp/call which utilizes a 48bit memory operand would have been invoked via the 'lcall/ljmp' mnemonic (intel style). This patch align those variants to formal intel spec Differential Revision: https://reviews.llvm.org/D35846 llvm-svn: 310485
* X86 Asm uses assertions instead of proper diagnostic. This patch fixes that.Andrew V. Tischenko2017-07-251-1/+44
| | | | | | Differential Revision: https://reviews.llvm.org/D35115 llvm-svn: 308972
* revert: [llvm] r308609 - This patch added some test cases to demonsrate the ↵Simon Pilgrim2017-07-201-50/+1
| | | | | | issues described in Bug 33848 - X86 Asm does not support symbolic names inside address calculation. llvm-svn: 308622
* This patch added some test cases to demonsrate the issues described in Bug ↵Andrew V. Tischenko2017-07-201-1/+50
| | | | | | 33848 - X86 Asm does not support symbolic names inside address calculation. llvm-svn: 308609
* [X86]Enable the use of 'mov' with a 64bit GPR and a large immediateCoby Tayree2017-01-251-0/+2
| | | | | | | | | | | Enable the next form (intel style): "mov <reg64>, <largeImm>" which is should be available, where <largeImm> stands for immediates which exceed the range of a singed 32bit integer Differential Revision: https://reviews.llvm.org/D28988 llvm-svn: 293030
* small fixup which enables the issuing of the aforementioned instruction (w/o ↵Coby Tayree2016-11-211-0/+2
| | | | | | | | operands), on MS/Intel syntax. Differential Revision: https://reviews.llvm.org/D26913 llvm-svn: 287548
* AVX512F: Add GATHER/SCATTER assembler Intel syntax tests for knl/skx/avx . ↵Igor Breger2016-02-251-2/+2
| | | | | | | | Change memory operand parser handling. Differential Revision: http://reviews.llvm.org/D17564 llvm-svn: 261862
* [X86] - Removing warning on legal cases caused by commit r258132Marina Yatsina2016-01-211-1/+16
| | | | | | | | | | | | | There's an overloading of the "movsd" and "cmpsd" instructions, e.g. movsd can be either "Move Data from String to String" or "Move or Merge Scalar Double-Precision Floating-Point Value". The former should produce warnings when parsing a memory operand that is not ESI/EDI, but the latter should not. Fixed the code to produce warnings only after making sure we're dealing with the first case. Expanded the tests of the produced warnings + fixed RUN line of the test so that it would check both stdout and stderr Differential Revision: http://reviews.llvm.org/D16359 llvm-svn: 258393
* [X86] Add support for "xlat m8"Marina Yatsina2016-01-191-0/+4
| | | | | | | | According to x86 spec "xlat m8" is a legal instruction and it is equivalent to "xlatb". Differential Revision: http://reviews.llvm.org/D15150 llvm-svn: 258135
* [X86] Adding support for missing variations of X86 string related instructionsMarina Yatsina2016-01-191-0/+24
| | | | | | | | | | | | | | | The following are legal according to X86 spec: ins mem, DX outs DX, mem lods mem stos mem scas mem cmps mem, mem movs mem, mem Differential Revision: http://reviews.llvm.org/D14827 llvm-svn: 258132
* dding test for fnstswMichael Zuckerman2015-12-081-0/+2
| | | | | | | | | | continue of Wrong FNSTSW size operator url: http://reviews.llvm.org/D14953 Differential Revision: http://reviews.llvm.org/D15155 llvm-svn: 255007
* [X86] Adding support for FWORD type for MS inline asmMarina Yatsina2015-12-071-0/+3
| | | | | | | | Adding support for FWORD type for MS inline asm. Differential Revision: http://reviews.llvm.org/D15268 llvm-svn: 254904
* [X86] Add support for loopz, loopnz for Intel syntaxMarina Yatsina2015-12-061-0/+5
| | | | | | | | According to x86 spec, loopz and loopnz should be supported for Intel syntax, where loopz is equivalent to loope and loopnz is equivalent to loopne. Differential Revision: http://reviews.llvm.org/D15148 llvm-svn: 254877
* [X86] Add support for fcomip, fucomip for Intel syntaxMarina Yatsina2015-12-031-0/+5
| | | | | | | | According to x86 spec, fcomip and fucomip should be supported for Intel syntax. Differential Revision: http://reviews.llvm.org/D15104 llvm-svn: 254595
* [x86] translating "fp" (floating point) instructions from ↵Michael Zuckerman2015-11-121-0/+14
| | | | | | | | | | | {fadd,fdiv,fmul,fsub,fsubr,fdivr} to {faddp,fdivp,fmulp,fsubp,fsubrp,fdivrp} LLVM Missing the following instructions: fadd\fdiv\fmul\fsub\fsubr\fdivr. GAS and MS supporting this instruction and lowering them in to a faddp\fdivp\fmulp\fsubp\fsubrp\fdivrp instructions. Differential Revision: http://reviews.llvm.org/D14217 llvm-svn: 252908
* [X86] Add support for mmword memory operand size for Intel-syntax x86 assemblyMichael Zuckerman2015-08-241-0/+3
| | | | | | Differential Revision: http://reviews.llvm.org/D12151 llvm-svn: 245835
* [X86] Fix FBLD and FBSTPMarina Yatsina2015-08-201-0/+5
| | | | | | | | | | FBLD and FBSTP should receive TBYTE because it is defined as FBLD m80 FBSTP m80 Differential Revision: http://reviews.llvm.org/D11748 llvm-svn: 245553
* [X86] Fix bug in COMISD and COMISS definition in td filesMarina Yatsina2015-08-201-0/+10
| | | | | | | | | | | | COMISD should receive QWORD because it is defined as (V)COMISD xmm1, xmm2/m64 COMISS should receive DWORD because it is defined as (V)COMISS xmm1, xmm2/m32 Differential Revision: http://reviews.llvm.org/D11712 llvm-svn: 245551
* [X86] Add SAL mnemonics for Intel syntaxMarina Yatsina2015-08-111-0/+3
| | | | | | | | SAL and SHL instructions perform the same operation Differential Revision: http://reviews.llvm.org/D11882 llvm-svn: 244588
* [X86] Fix REPE, REPZ, REPNZ for intel syntaxMarina Yatsina2015-08-111-0/+13
| | | | | | | | | REPE, REPZ, REPNZ, REPNE should have mnemonics for Intel syntax as well. Currently using these instructions causes compilation errors for Intel syntax. Differential Revision: http://reviews.llvm.org/D11794 llvm-svn: 244584
* [X86] Fix imul alias for intel syntaxMarina Yatsina2015-08-111-0/+7
| | | | | | | | | The "imul reg, imm" alias is not defined for intel syntax. In intel syntax there is no w/l/q suffix for the imul instruction. Differential Revision: http://reviews.llvm.org/D11887 llvm-svn: 244582
* [X86] Fix order of operands for ins and outs instructions when parsing intel ↵Michael Kuperstein2015-07-231-0/+14
| | | | | | | | | syntax Patch by: marina.yatsina@intel.com Differential Revision: http://reviews.llvm.org/D11337 llvm-svn: 243001
* [X86] Add support for tbyte memory operand size for Intel-syntax x86 assemblyMichael Kuperstein2015-07-191-0/+2
| | | | | | | Differential Revision: http://reviews.llvm.org/D11257 Patch by: marina.yatsina@intel.com llvm-svn: 242639
* [TableGen][AsmMatcherEmitter] Only parse isolated tokens as registers.Ahmed Bougacha2015-05-291-0/+3
| | | | | | | | | | | | | | Fixes PR23455, where, when TableGen generates the matcher from the AsmString, it splits "cmp${cc}ss" into tokens, and the "ss" suffix is recognized as the SS register. I can't think of a situation where that's a feature, not a bug, hence: when a token is "isolated", i.e., it is followed and preceded by separators, it shouldn't be parsed as a register. Differential Revision: http://reviews.llvm.org/D9844 llvm-svn: 238536
* [X86] Make fxsave64/fxrstor64/xsave64/xsrstor64/xsaveopt64 parseable in AT&T ↵Craig Topper2015-02-031-2/+2
| | | | | | syntax. Also make them the default output. llvm-svn: 227963
* MC: Use @IMGREL instead of @IMGREL32, which we can't parseReid Kleckner2014-09-251-1/+1
| | | | | | | | | | | | Nico Rieck added support for this 32-bit COFF relocation some time ago for Win64 stuff. It appears that as an oversight, the assembly output used "foo"@IMGREL32 instead of "foo"@IMGREL, which is what we can parse. Sadly, there were actually tests that took in IMGREL and put out IMGREL32, and we didn't notice the inconsistency. Oh well. Now LLVM can assemble it's own output with slightly more fidelity. llvm-svn: 218437
* X86 MC: Handle instructions like fxsave that match multiple operand sizesReid Kleckner2014-08-271-2/+23
| | | | | | | | | | | | | | | | Instructions like 'fxsave' and control flow instructions like 'jne' match any operand size. The loop I added to the Intel syntax matcher assumed that using a different size would give a different instruction. Now it handles the case where we get the same instruction for different memory operand sizes. This also allows us to remove the hack we had for unsized absolute memory operands, because we can successfully match things like 'jnz' without reporting ambiguity. Removing this hack uncovered test case involving 'fadd' that was ambiguous. The memory operand could have been single or double precision. llvm-svn: 216604
* MC: Split the x86 asm matcher implementations by dialectReid Kleckner2014-08-261-0/+34
| | | | | | | | | | | | | | | | | | | The existing matcher has lots of AT&T assembly dialect assumptions baked into it. In particular, the hack for resolving the size of a memory operand by appending the four most common suffixes doesn't work at all. The Intel assembly dialect mnemonic table has ambiguous entries, so we need to try matching multiple times with different operand sizes, since that's the only way to choose different instruction variants. This makes us more compatible with gas's implementation of Intel assembly syntax. MSVC assumes you want byte-sized operations for the instructions that we reject as ambiguous. Reviewed By: grosbach Differential Revision: http://reviews.llvm.org/D4747 llvm-svn: 216481
* MS asm: Properly handle quoted symbol namesDavid Majnemer2014-06-191-0/+8
| | | | | | | | | | | | | We would get confused by '@' characters in symbol names, we would mistake the text following them for the variant kind. When an identifier a string, the variant kind will never show up inside of it. Instead, check to see if there is a variant following the string. This fixes PR19965. llvm-svn: 211249
* MC: Fix Intel assembly parser for [global + offset]Reid Kleckner2014-03-041-0/+9
| | | | | | | | | We were dropping the displacement on the floor if we also had some immediate offset. Should fix PR19033. llvm-svn: 202774
* Teach x86 asm parser to handle 'opaque ptr' in Intel syntax.Craig Topper2014-01-171-2/+2
| | | | llvm-svn: 199477
* Fix intel syntax for 64-bit version of FXSAVE/FXRSTOR to use '64' suffix ↵Craig Topper2014-01-171-0/+6
| | | | | | instead of 'q' llvm-svn: 199474
* Fixing Intel format of the vshufpd instruction.Yunzhong Gao2013-09-271-0/+2
| | | | | | Phabricator code review is located at: http://llvm-reviews.chandlerc.com/D1759 llvm-svn: 191481
OpenPOWER on IntegriCloud