summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/X86/AsmParser/X86Operand.h
Commit message (Collapse)AuthorAgeFilesLines
* [ms] [X86] Use "P" modifier on all branch-target operands in inline X86 ↵Eric Astor2020-01-091-3/+0
| | | | | | | | | | | | | | | | | | | assembly. Summary: Extend D71677 to apply to all branch-target operands, rather than special-casing call instructions. Also add a regression test for llvm.org/PR44272, since this finishes fixing it. Reviewers: thakis, rnk Reviewed By: thakis Subscribers: merge_guards_bot, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72417
* [X86][AsmParser] re-introduce 'offset' operatorEric Astor2019-12-301-8/+12
| | | | | | | | | | | | | | | | | | | | | | | Summary: Amend MS offset operator implementation, to more closely fit with its MS counterpart: 1. InlineAsm: evaluate non-local source entities to their (address) location 2. Provide a mean with which one may acquire the address of an assembly label via MS syntax, rather than yielding a memory reference (i.e. "offset asm_label" and "$asm_label" should be synonymous 3. address PR32530 Based on http://llvm.org/D37461 Fix broken test where the break appears unrelated. - Set up appropriate memory-input rewrites for variable references. - Intel-dialect assembly printing now correctly handles addresses by adding "offset". - Pass offsets as immediate operands (using "r" constraint for offsets of locals). Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D71436
* [ms] [X86] Use "P" modifier on operands to call instructions in inline X86 ↵Eric Astor2019-12-221-1/+5
| | | | | | | | | | | | | | | | | | | | assembly. Summary: This is documented as the appropriate template modifier for call operands. Fixes PR44272, and adds a regression test. Also adds support for operand modifiers in Intel-style inline assembly. Reviewers: rnk Reviewed By: rnk Subscribers: merge_guards_bot, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71677
* X86Operand::print - fix SymName shadow variable warning. NFCI.Simon Pilgrim2019-11-021-2/+2
|
* [X86] Use Register/MCRegister in more places in X86Craig Topper2019-08-161-1/+1
| | | | | | | | | | This was a quick pass through some obvious places. I haven't tried the clang-tidy check. I also replaced the zeroes in getX86SubSuperRegister with X86::NoRegister which is the real sentinel name. Differential Revision: https://reviews.llvm.org/D66363 llvm-svn: 369151
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-151-7/+7
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* [X86] Improve the diagnostic for larger than 4-bit immediate for ↵Craig Topper2019-08-101-3/+3
| | | | | | vpermil2pd/ps. Only allow MCConstantExprs. llvm-svn: 368505
* [X86] Limit vpermil2pd/vpermil2ps immediates to 4 bits in the assembly parser.Craig Topper2019-08-071-0/+9
| | | | | | | | | | The upper 4 bits of the immediate byte are used to encode a register. We need to limit the explicit immediate to fit in the remaining 4 bits. Fixes PR42899. llvm-svn: 368123
* [X86] Add VP2INTERSECT instructionsPengfei Wang2019-05-311-0/+49
| | | | | | | | | | Support Intel AVX512 VP2INTERSECT instructions in llvm Patch by Xiang Zhang (xiangzhangllvm) Differential Revision: https://reviews.llvm.org/D62366 llvm-svn: 362188
* [X86] Move InstPrinter files to MCTargetDesc. NFCRichard Trieu2019-05-101-1/+1
| | | | | | | | | For some targets, there is a circular dependency between InstPrinter and MCTargetDesc. Merging them together will fix this. For the other targets, the merging is to maintain consistency so all targets will have the same structure. llvm-svn: 360484
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Undo r350355 "[X86] Remove terrible DX Register parsing hack in parse ↵Nirav Dave2019-01-041-5/+10
| | | | | | | | operand. NFCI." Add missing test case and update comments. llvm-svn: 350406
* [X86] Remove terrible DX Register parsing hack in parse operand. NFCI.Nirav Dave2019-01-031-10/+5
| | | | | | | Fold hack special casing of (%dx) operand parsing into the related hack for out*/in* instruction parsing. llvm-svn: 350355
* [X86][AsmParser] Rework the in/out (%dx) hack one more time.Craig Topper2018-07-031-1/+10
| | | | | | | | This patch adds a new token type specifically for (%dx). We will now always create this token when we parse (%dx). After all operands have been parsed, if the mnemonic is in/out we'll morph this token to a regular register token. Otherwise we keep it as the special DX token which won't match any instructions. This removes the need for passing Mnemonic through the parsing functions. It also seems closer to gas where when its used on the wrong instruction it just gets diagnosed as an invalid operand rather than a bad memory address. llvm-svn: 336218
* [X86] Add encoding information for the AVX5124FMAPS and AVX5124VNNIW ↵Craig Topper2018-06-021-1/+1
| | | | | | | | | | instructions so they can be assembled and disassembled. These instructions are unusual in that they operate on 4 consecutive registers so supporting them in codegen will be more difficult than normal. Includes an assembler check to warn if the source register is not the first register of a 4 register group. llvm-svn: 333812
* [X86] Use getX86SubSuperRegister in addGR32orGR64Operands in the AsmParser ↵Craig Topper2018-04-291-24/+1
| | | | | | instead of duplicating its functionality. NFC llvm-svn: 331128
* Implementation of X86Operand::print.Andrew V. Tischenko2018-01-111-2/+48
| | | | | | Differential Revision: https://reviews.llvm.org/D41610 llvm-svn: 322267
* X86Operand.h: Include X86MCTargetDesc.h for SSE register enum/namesDavid Blaikie2017-10-241-0/+1
| | | | llvm-svn: 316506
* This patch is a result of D37262: The issues with X86 prefixes. It closes ↵Andrew V. Tischenko2017-10-161-6/+19
| | | | | | PR7709, PR17697, PR19251, PR32809 and PR21640. There could be other bugs closed by this patch. llvm-svn: 315899
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* Initialize new member X86Operand::FrontendSize in all codepaths.Daniel Jasper2017-05-051-1/+2
| | | | | | This fixes MSAN-builds after r302179. llvm-svn: 302214
* [ms-inline-asm] Use the frontend size only for ambiguous instructionsReid Kleckner2017-05-041-1/+10
| | | | | | | | | | | | | | | | | | This avoids problems on code like this: char buf[16]; __asm { movups xmm0, [buf] mov [buf], eax } The frontend size in this case (1) is wrong, and the register makes the instruction matching unambiguous. There are also enough bytes available that we shouldn't complain to the user that they are potentially using an incorrectly sized instruction to access the variable. Supersedes D32636 and D26586 and fixes PR28266 llvm-svn: 302179
* [X86] Fix some Include What You Use warnings; other minor fixes (NFC).Eugene Zelenko2017-02-061-5/+16
| | | | | | This is preparation to reduce MCExpr.h dependencies.(vlsj-clangbuild)[622] llvm-svn: 294246
* [AVX-512] Correct memory operand size for VPGATHERQPS and VPGATHERQDCraig Topper2017-01-161-0/+3
| | | | | | | | | with ZMM index. Similar for SCATTER and the prefetch gather and scatter instructions. Fixes PR31618. llvm-svn: 292088
* X86: Allow expressions to appear as u8imm operands.Peter Collingbourne2016-10-201-1/+3
| | | | llvm-svn: 284688
* Revert r283690, "MC: Remove unused entities."Peter Collingbourne2016-10-101-3/+11
| | | | llvm-svn: 283814
* MC: Remove unused entities.Peter Collingbourne2016-10-091-11/+3
| | | | llvm-svn: 283691
* AVX512F: Add GATHER/SCATTER assembler Intel syntax tests for knl/skx/avx . ↵Igor Breger2016-02-251-30/+31
| | | | | | | | Change memory operand parser handling. Differential Revision: http://reviews.llvm.org/D17564 llvm-svn: 261862
* AVX-512: Added all SKX forms of GATHER instructions.Elena Demikhovsky2015-06-281-0/+16
| | | | | | | Added intrinsics. Added encoding and tests. llvm-svn: 240905
* Remove 3 includes from MCInstrDesc.h and explicitly include them where neededPete Cooper2015-05-151-0/+3
| | | | llvm-svn: 237481
* MC: Modernize MCOperand API naming. NFC.Jim Grosbach2015-05-131-16/+16
| | | | | | MCOperand::Create*() methods renamed to MCOperand::create*(). llvm-svn: 237275
* AVX-512: Add assembly parser support for Rounding modeElena Demikhovsky2015-03-021-1/+7
| | | | | | By Asaf Badouh <asaf.badouh@intel.com> llvm-svn: 230962
* [X86] Remove the AbsMem32 type from the assembly parser. Only really need ↵Craig Topper2015-02-241-4/+0
| | | | | | the 16-bit version which will automatically get prioritized over AbsMem. llvm-svn: 230313
* [x86] Add assembly parser bounds checking to the immediate value for ↵Craig Topper2015-01-211-0/+7
| | | | | | cmpss/cmpsd/cmpps/cmppd. llvm-svn: 226642
* [X86] Add OpSize32 to XBEGIN_4. Add XBEGIN_2 with OpSize16.Craig Topper2015-01-061-0/+8
| | | | | | Requires new AsmParserOperand types that detect 16-bit and 32/64-bit mode so that we choose the right instruction based on default sizing without predicates. This is necessary since predicates mess up the disassembler table building. llvm-svn: 225256
* [X86] Disassembler support for move to/from %rax with a 32-bit memory offset ↵Craig Topper2015-01-031-0/+3
| | | | | | is REX.W and AdSize prefix are both present. llvm-svn: 225099
* [X86] Make the instructions that use AdSize16/32/64 co-exist together ↵Craig Topper2015-01-021-17/+44
| | | | | | | | | | without using mode predicates. This is necessary to allow the disassembler to be able to handle AdSize32 instructions in 64-bit mode when address size prefix is used. Eventually we should probably also support 'addr32' and 'addr16' in the assembler to override the address size on some of these instructions. But for now we'll just use special operand types that will lookup the current mode size to select the right instruction. llvm-svn: 225075
* [x86] Fix a pretty horrible bug and inconsistency in the x86 asmChandler Carruth2014-09-061-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | parsing (and latent bug in the instruction definitions). This is effectively a revert of r136287 which tried to address a specific and narrow case of immediate operands failing to be accepted by x86 instructions with a pretty heavy hammer: it introduced a new kind of operand that behaved differently. All of that is removed with this commit, but the test cases are both preserved and enhanced. The core problem that r136287 and this commit are trying to handle is that gas accepts both of the following instructions: insertps $192, %xmm0, %xmm1 insertps $-64, %xmm0, %xmm1 These will encode to the same byte sequence, with the immediate occupying an 8-bit entry. The first form was fixed by r136287 but that broke the prior handling of the second form! =[ Ironically, we would still emit the second form in some cases and then be unable to re-assemble the output. The reason why the first instruction failed to be handled is because prior to r136287 the operands ere marked 'i32i8imm' which forces them to be sign-extenable. Clearly, that won't work for 192 in a single byte. However, making thim zero-extended or "unsigned" doesn't really address the core issue either because it breaks negative immediates. The correct fix is to make these operands 'i8imm' reflecting that they can be either signed or unsigned but must be 8-bit immediates. This patch backs out r136287 and then changes those places as well as some others to use 'i8imm' rather than one of the extended variants. Naturally, this broke something else. The custom DAG nodes had to be updated to have a much more accurate type constraint of an i8 node, and a bunch of Pat immediates needed to be specified as i8 values. The fallout didn't end there though. We also then ceased to be able to match the instruction-specific intrinsics to the instructions so modified. Digging, this is because they too used i32 rather than i8 in their signature. So I've also switched those intrinsics to i8 arguments in line with the instructions. In order to make the intrinsic adjustments of course, I also had to add auto upgrading for the intrinsics. I suspect that the intrinsic argument types may have led everything down this rabbit hole. Pretty happy with the result. llvm-svn: 217310
* MC: Split the x86 asm matcher implementations by dialectReid Kleckner2014-08-261-0/+3
| | | | | | | | | | | | | | | | | | | 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
* Canonicalize header guards into a common format.Benjamin Kramer2014-08-131-3/+3
| | | | | | | | | | Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
* AsmMatchers: Use unique_ptr to manage ownership of MCParsedAsmOperandDavid Blaikie2014-06-081-21/+21
| | | | | | | | | | | | I saw at least a memory leak or two from inspection (on probably untested error paths) and r206991, which was the original inspiration for this change. I ran this idea by Jim Grosbach a few weeks ago & he was OK with it. Since it's a basically mechanical patch that seemed sufficient - usual post-commit review, revert, etc, as needed. llvm-svn: 210427
* [C++] Use 'nullptr'.Craig Topper2014-04-281-3/+3
| | | | llvm-svn: 207394
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-091-13/+13
| | | | | | class. llvm-svn: 203418
* X86Operand is extracted into individual header.Evgeniy Stepanov2014-02-281-0/+488
X86Operand is extracted into individual header, because it allows to create an arbitrary memory operand and append it to MCInst. It'll be reused in X86 inline assembly instrumentation. Patch by Yuri Gorshenin. llvm-svn: 202496
OpenPOWER on IntegriCloud