summaryrefslogtreecommitdiffstats
path: root/llvm/test/MC/X86
Commit message (Collapse)AuthorAgeFilesLines
...
* [X86] And also test INSERTPS shuffle mask pretty-printing.Ahmed Bougacha2014-12-151-0/+5
| | | | | | For r224260. llvm-svn: 224264
* [AVX512] Added VPBROADCAST{BWDQ} (Load with Broadcast Integer Data from ↵Robert Khasanov2014-12-094-0/+180
| | | | | | | | | General Purpose Register) encodings for AVX512-BW/VL subsets Added encoding tests. llvm-svn: 223787
* [CompactUnwind] Fix register encoding logicBruno Cardoso Lopes2014-12-081-0/+72
| | | | | | | | | | | | Fix a compact unwind encoding logic bug which would try to encode more callee saved registers than it should, leading to early bail out in the encoding logic and abusive use of DWARF frame mode unnecessarily. Also remove no-compact-unwind.ll which was testing the wrong thing based on this bug and move it to valid 'compact unwind' tests. Added other few more tests too. llvm-svn: 223676
* [X86][MC] Intel syntax: accept implicit memory operand sizes larger than 80.Ahmed Bougacha2014-12-031-0/+26
| | | | | | | | | | The X86AsmParser intel handling was refactored in r216481, making it try each different memory operand size to see which one matches. Operand sizes larger than 80 ("[xyz]mmword ptr") were forgotten, which led to an "invalid operand" error for code such as: movdqa [rax], xmm0 llvm-svn: 223187
* Revert "Reapply 222538 and update tests to explicitly request small code ↵Rafael Espindola2014-11-271-3/+1
| | | | | | | | | | | | | | | | model and PIC:" This reverts commit r222760. It changed our behaviour on PIC so we don't match gas anymore. It also included lots of unnecessary changes to tests. If those changes are desirable, there should be an independent discussion as they are out of scope for that patch. I will recommit the other bits. llvm-svn: 222896
* Reapply 222538 and update tests to explicitly request small code modelJoerg Sonnenberger2014-11-251-1/+3
| | | | | | | | | | | | | | | and PIC: Allow FDE references outside the +/-2GB range supported by PC relative offsets for code models other than small/medium. For JIT application, memory layout is less controlled and can result in truncations otherwise. Patch from Akos Kiss. Differential Revision: http://reviews.llvm.org/D6079 llvm-svn: 222760
* Don't produce relocations for a difference in a section with no symbols.Rafael Espindola2014-11-041-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | We were producing a relocation for ---------------- .section foo,bar La: Lb: .long La-Lb -------------- but not for --------------------- .section foo,bar zed: La: Lb: .long La-Lb ---------------- This patch handles the case where both fragments are part of the first atom in a section and there is no corresponding symbol to that atom. This fixes pr21328. llvm-svn: 221304
* [AVX512] Added VBROADCAST{SS/SD} encoding for VL subset.Robert Khasanov2014-10-302-0/+220
| | | | | | | Refactored through AVX512_maskable llvm-svn: 220908
* [AVX512] Implemented AVX512VL FP bnary packed instructions (VADDP*, VSUBP*, ↵Robert Khasanov2014-10-291-0/+1344
| | | | | | | | | VMULP*, VDIVP*, VMAXP*, VMINP*) Refactored through AVX512_maskable Added encoding tests for them. llvm-svn: 220858
* [AVX512] Extended avx512_sqrt_packed (sqrt instructions) to VL subset.Robert Khasanov2014-10-282-0/+336
| | | | | | Refactored through AVX512_maskable llvm-svn: 220806
* [AVX-512] Expanded rsqrt/rcp instructions to VL subset.Robert Khasanov2014-10-282-0/+672
| | | | | | Refactored multiclass through AVX512_maskable llvm-svn: 220783
* [AVX512] Add vpermil variable versionAdam Nemet2014-10-271-0/+16
| | | | | | | | | This is implemented via a multiclass that derives from the vperm imm multiclass. Fixes <rdar://problem/18426089> llvm-svn: 220737
* [AVX512] FMA support for the 231 variantsAdam Nemet2014-10-241-0/+24
| | | | | | | | | | | | | | | | | This is asm/diasm-only support, similar to AVX. For ISeling the register variant, they are no different from 213 other than whether the multiplication or the addition operand is destructed. For ISeling the memory variant, i.e. to fold a load, they are no different than the 132 variant. The addition operand (op3) in both cases can come from memory. Again the ony difference is which operand is destructed. There could be a post-RA pass that would convert a 213 or 132 into a 231. Part of <rdar://problem/17082571> llvm-svn: 220540
* [MC] Attach labels to existing fragments instead of using a separate fragmentDerek Schuff2014-10-222-1/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently when emitting a label, a new data fragment is created for it if the current fragment isn't a data fragment. This change instead enqueues the label and attaches it to the next fragment (e.g. created for the next instruction) if possible. When bundle alignment is not enabled, this has no functionality change (it just results in fewer extra fragments being created). For bundle alignment, previously labels would point to the beginning of the bundle padding instead of the beginning of the emitted instruction. This was not only less efficient (e.g. jumping to the nops instead of past them) but also led to miscalculation of the address of the GOT (since MC uses a label difference rather than emitting a "." symbol). Fixes https://code.google.com/p/nativeclient/issues/detail?id=3982 Test Plan: regression test attached Reviewers: jvoung, eliben Subscribers: jfb, llvm-commits Differential Revision: http://reviews.llvm.org/D5915 llvm-svn: 220439
* [AVX512] Add DQ subvector insertsAdam Nemet2014-10-151-0/+8
| | | | | | | | | | | | | | In AVX512f we support 64x2 and 32x8 inserts via matching them to 32x4 and 64x4 respectively. These are matched by "Alt" Pat<>'s (Alt stands for alternative VTs). Since DQ has native support for these intructions, I peeled off the non-"Alt" part of the baseclass into vinsert_for_size_no_alt. The DQ instructions are derived from this multiclass. The "Alt" Pat<>'s are disabled with DQ. Fixes <rdar://problem/18426089> llvm-svn: 219874
* [MC] Make bundle alignment mode setting idempotent and support nested bundlesDerek Schuff2014-10-151-0/+67
| | | | | | | | | | | | | | | | | | | | | | Summary: Currently an error is thrown if bundle alignment mode is set more than once per module (either via the API or the .bundle_align_mode directive). This change allows setting it multiple times as long as the alignment doesn't change. Also nested bundle_lock groups are currently not allowed. This change allows them, with the effect that the group stays open until all nests are exited, and if any of the bundle_lock directives has the align_to_end flag, the group becomes align_to_end. These changes make the bundle aligment simpler to use in the compiler, and also better match the corresponding support in GNU as. Reviewers: jvoung, eliben Differential Revision: http://reviews.llvm.org/D5801 llvm-svn: 219811
* [x86 asm] allow fwait alias in both At&t and Intel modes (PR21208)Hans Wennborg2014-10-141-0/+4
| | | | | | Differential Revision: http://reviews.llvm.org/D5741 llvm-svn: 219725
* [AVX512] Extended avx512_binop_rm to DQ/VL subsets.Robert Khasanov2014-10-142-1/+170
| | | | | | Added encoding tests. llvm-svn: 219686
* [AVX512] Extended avx512_binop_rm to BW/VL subsets.Robert Khasanov2014-10-142-2/+1406
| | | | | | Added encoding tests. llvm-svn: 219685
* [AVX512] Extended avx512_binop_rm for AVX512VL subsets.Robert Khasanov2014-10-091-1/+2353
| | | | | | | Added avx512_binop_rm_vl multiclass for VL subset Added encoding tests llvm-svn: 219390
* [AVX512] Add asm-only support for vextract*x4 masking variantsAdam Nemet2014-10-081-0/+8
| | | | | | | | | | | | | | | | These derive from the new asm-only masking definitions. Unfortunately I wasn't able to find a ISel pattern that we could legally generate for the masking variants. The problem is that since the destination is v4* we would need VK4 register classes and v4i1 value types to express the masking. These are however not legal types/classes in AVX512f but only in VL, so things get complicated pretty quickly. We can revisit this question later if we have a more pressing need to express something like this. So the ISel patterns are empty for the masking instructions and the next patch will add Pat<>s instead to match the intrinsics calls with instructions. llvm-svn: 219361
* 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] Fix a pretty horrible bug and inconsistency in the x86 asmChandler Carruth2014-09-061-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* X86 MC: Handle instructions like fxsave that match multiple operand sizesReid Kleckner2014-08-272-2/+26
| | | | | | | | | | | | | | | | 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
* [SKX] Added new versions of cmp instructions in avx512_icmp_cc multiclass, ↵Robert Khasanov2014-08-274-0/+1104
| | | | | | | | added VL multiclass. Added encoding tests llvm-svn: 216532
* MC: Split the x86 asm matcher implementations by dialectReid Kleckner2014-08-263-0/+98
| | | | | | | | | | | | | | | | | | | 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
* [SKX] avx512_icmp_packed multiclass extensionRobert Khasanov2014-08-254-0/+1008
| | | | | | | | | | | | | Extended avx512_icmp_packed multiclass by masking versions. Added avx512_icmp_packed_rmb multiclass for embedded broadcast versions. Added corresponding _vl multiclasses. Added encoding tests for CPCMP{EQ|GT}* instructions. Add more fields for X86VectorVTInfo. Added AVX512VLVectorVTInfo that include X86VectorVTInfo for 512/256/128-bit versions Differential Revision: http://reviews.llvm.org/D5024 llvm-svn: 216383
* Remove HasLEB128.Rafael Espindola2014-08-151-0/+7
| | | | | | We already require CFI, so it should be safe to require .leb128 and .uleb128. llvm-svn: 215712
* [SKX] Extended non-temporal load/store instructions for AVX512VL subsets.Robert Khasanov2014-08-132-0/+288
| | | | | | | | | Added avx512_movnt_vl multiclass for handling 256/128-bit forms of instruction. Added encoding and lowering tests. Reviewed by Elena Demikhovsky <elena.demikhovsky@intel.com> llvm-svn: 215536
* Add missing test for r215031Reid Kleckner2014-08-111-0/+13
| | | | llvm-svn: 215374
* MC X86: Accept ".att_syntax prefix" and diagnose noprefixReid Kleckner2014-08-061-0/+8
| | | | | | | | Fixes PR18916. I don't think we need to implement support for either hybrid syntax. Nobody should write Intel assembly with '%' prefixes on their registers or AT&T assembly without them. llvm-svn: 215031
* [X86] Fixes commit r214890 to match the posted patchAdam Nemet2014-08-061-1/+5
| | | | | | This was another fallout from my local rebase where something went wrong :( llvm-svn: 214951
* [AVX512] Add masking variant and intrinsics for valignd/qAdam Nemet2014-08-051-0/+4
| | | | | | | | | | | | | This is similar to what I did with the two-source permutation recently. (It's almost too similar so that we should consider generating the masking variants with some tablegen help.) Both encoding and intrinsic tests are added as well. For the latter, this is what the IR that the intrinsic test on the clang side generates. Part of <rdar://problem/17688758> llvm-svn: 214890
* [SKX] Enabling load/store instructions: encodingRobert Khasanov2014-08-044-0/+1922
| | | | | | | | Instructions: VMOVAPD, VMOVAPS, VMOVDQA8, VMOVDQA16, VMOVDQA32,VMOVDQA64, VMOVDQU8, VMOVDQU16, VMOVDQU32,VMOVDQU64, VMOVUPD, VMOVUPS, Reviewed by Elena Demikhovsky <elena.demikhovsky@intel.com> llvm-svn: 214719
* Add support for the X86 secure guard extensions instructions in assembler (SGX).Kevin Enderby2014-07-311-0/+9
| | | | | | | | | | | | | This allows assembling the two new instructions, encls and enclu for the SKX processor model. Note the diffs are a bigger than what might think, but to fit the new MRM_CF and MRM_D7 in things in the right places things had to be renumbered and shuffled down causing a bit more diffs. rdar://16228228 llvm-svn: 214460
* X86 MC: Don't crash on empty memory operand parensReid Kleckner2014-07-311-0/+5
| | | | | | | | Instead, create an absolute memory operand. Fixes PR20504. llvm-svn: 214457
* X86 MC: Reject invalid segment registers before a memory operand colonReid Kleckner2014-07-311-0/+4
| | | | | | Previously we would execute unreachable during object emission. llvm-svn: 214456
* [SKX] Enabling mask logic instructions: encoding, loweringRobert Khasanov2014-07-283-0/+84
| | | | | | | | Instructions: KAND{BWDQ}, KANDN{BWDQ}, KOR{BWDQ}, KXOR{BWDQ}, KXNOR{BWDQ} Reviewed by Elena Demikhovsky <elena.demikhovsky@intel.com> llvm-svn: 214081
* [X86] Add comments to clarify some non-obvious lines in the stackmap-nops.llLang Hames2014-07-251-0/+3
| | | | | | | | testcases. Based on code review from Philip Reames. Thanks Philip! llvm-svn: 213923
* [X86] Optimize stackmap shadows on X86.Lang Hames2014-07-241-0/+1
| | | | | | | | | | | | | | | | | | | This patch minimizes the number of nops that must be emitted on X86 to satisfy stackmap shadow constraints. To minimize the number of nops inserted, the X86AsmPrinter now records the size of the most recent stackmap's shadow in the StackMapShadowTracker class, and tracks the number of instruction bytes emitted since the that stackmap instruction was encountered. Padding is emitted (if it is required at all) immediately before the next stackmap/patchpoint instruction, or at the end of the basic block. This optimization should reduce code-size and improve performance for people using the llvm stackmap intrinsic on X86. <rdar://problem/14959522> llvm-svn: 213892
* X86: correct library call setup for Windows itaniumSaleem Abdulrasool2014-07-241-0/+16
| | | | | | | | This target is identical to the Windows MSVC (and follows Microsoft ABI for C). Correct the library call setup for this target. The same set of library calls are missing on this environment. llvm-svn: 213883
* [SKX] Added missed test files for rev 213757Robert Khasanov2014-07-232-0/+138
| | | | llvm-svn: 213780
* [SKX] Fix lowercase "error:" in rev 213757Robert Khasanov2014-07-231-22/+22
| | | | llvm-svn: 213774
* [SKX] Enabling mask instructions: encoding, loweringRobert Khasanov2014-07-231-0/+48
| | | | | | | | KMOVB, KMOVW, KMOVD, KMOVQ, KNOTB, KNOTW, KNOTD, KNOTQ Reviewed by Elena Demikhovsky <elena.demikhovsky@intel.com> llvm-svn: 213757
* MC: fix MCAsmInfo usage for windows-itaniumSaleem Abdulrasool2014-07-171-0/+6
| | | | | | Windows itanium uses the GNUCOFF assmebly format, not ELF. llvm-svn: 213274
* [X86] AVX512: Only allow k1-k7 as predicates to vpcmp*Adam Nemet2014-07-081-1/+5
| | | | | | | | | As destination k0 is allowed but not as predicate/writemask. I also modified the test to allow checking of error messages by the assembler. I applied a similar approach to the test ret.s in the same directory. llvm-svn: 212504
* Revert r212375 because of test failuresEhsan Akhgari2014-07-051-4/+0
| | | | llvm-svn: 212376
* Add a test case for the tilde operator in Microsoft inline assemblyEhsan Akhgari2014-07-051-0/+4
| | | | llvm-svn: 212375
* [X86] Limit maximum nop length on SilvermontAlexey Volkov2014-07-042-0/+11
| | | | | | | | | | | Silvermont can only decode one instruction per cycle if the instruction exceeds 8 bytes. Also in Silvermont instructions with more than 3 prefixes will cause 3 cycle penalty. Maximum nop length is limited to 7 bytes when used for padding on Silvermont. For other x86 processors max nop length remains unchanged 15 bytes. Differential Revision: http://reviews.llvm.org/D4374 llvm-svn: 212321
* [X86] AVX512: Add writemask variants for vperm*2*Adam Nemet2014-07-021-0/+16
| | | | | | | | | This includes assembler and codegen support (see the new tests in avx512-encodings.s and avx512-shuffle.ll). <rdar://problem/17492620> llvm-svn: 212221
OpenPOWER on IntegriCloud