summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/X86/AsmParser/X86Operand.h
Commit message (Collapse)AuthorAgeFilesLines
* 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