summaryrefslogtreecommitdiffstats
path: root/llvm/test/MC
Commit message (Collapse)AuthorAgeFilesLines
...
* [X86] Move files to correct directories after D60552Fangrui Song2019-05-0616-0/+2015
| | | | llvm-svn: 360022
* [hexagon] change AsmParser assertion to errorBrian Cain2019-05-032-0/+12
| | | | | | | For immediates that can't be evaluated in assembler-mapped instructions, we should return 'invalid operand' instead of assert. llvm-svn: 359905
* [X86] Allow assembly parser to accept x/y/z suffixes on non-memory ↵Craig Topper2019-05-033-2/+477
| | | | | | | | | | | | vfpclassps/pd and on memory forms in intel syntax The x/y/z suffix is needed to disambiguate the memory form in at&t syntax since no xmm/ymm/zmm register is mentioned. But we should also allow it for the register and broadcast forms where its not needed for consistency. This matches gas. The printing code will still only use the suffix for the memory form where it is needed. llvm-svn: 359903
* [AArch64][MC] Reject "add x0, x1, w2, lsl #1" etc.Eli Friedman2019-05-031-2/+6
| | | | | | | | | | Looks like just a minor oversight in the parsing code. Fixes https://bugs.llvm.org/show_bug.cgi?id=41504. Differential Revision: https://reviews.llvm.org/D60840 llvm-svn: 359855
* [AMDGPU] gfx1010 allows VOP3 to have a literalStanislav Mekhanoshin2019-05-0210-52/+442
| | | | | | Differential Revision: https://reviews.llvm.org/D61413 llvm-svn: 359756
* [X86] Remove the redundant suffix in vfpclassp[d,s]'s broadcasting variantCraig Topper2019-05-022-120/+120
| | | | | | | | | | The broadcasting variant for instruction vfpclassp[d,s] shouldn't use suffix q/l. So remove them from the template. Patch by Pengfei Wang Differential Revision: https://reviews.llvm.org/D61295 llvm-svn: 359753
* [AMDGPU] gfx1010 MIMG implementationStanislav Mekhanoshin2019-05-015-0/+866
| | | | | | Differential Revision: https://reviews.llvm.org/D61339 llvm-svn: 359698
* [AMDGPU] gfx1010 DS implementationStanislav Mekhanoshin2019-05-011-0/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D61332 llvm-svn: 359696
* [tests] Add host-byteorder-*-endian; update XFAILs of big-endian triplesHubert Tong2019-05-012-2/+2
| | | | | | | | | | | | | | | | | | | | Summary: Triple components in `XFAIL` lines are tested against the target triple. Various tests that are expected to fail on big-endian hosts are marked as being `XFAIL` for big-endian targets. This patch corrects these tests by having them test against a new `host-byteorder-big-endian` feature. Reviewers: xingxue, sfertile, jasonliu Reviewed By: xingxue Subscribers: jvesely, nhaehnle, fedor.sergeev, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60551 llvm-svn: 359689
* [llvm-objdump] Print newlines before and after "Disassembly of section ...:"Fangrui Song2019-05-016-4/+31
| | | | | | | | | | | This improves readability and the behavior is consistent with GNU objdump. The new test test/tools/llvm-objdump/X86/disassemble-section-name.s checks we print newlines before and after "Disassembly of section ...:" Differential Revision: https://reviews.llvm.org/D61127 llvm-svn: 359668
* [llvm-readobj] Change -t to --symbols in tests. NFCFangrui Song2019-05-01132-142/+142
| | | | | | | | | | -t is --symbols in llvm-readobj but --section-details (unimplemented) in readelf. The confusing option should not be used since we aim for improving compatibility. Keep just one llvm-readobj -t use case in test/tools/llvm-readobj/symbols.test llvm-svn: 359661
* [llvm-readobj] llvm-readobj --elf-output-style=GNU => llvm-readelf. NFCFangrui Song2019-05-011-1/+1
| | | | | | | | | The latter is much more common. A dedicated --elf-output-style=GNU test demonstrating it is the same as llvm-readelf is sufficient. llvm-svn: 359652
* [llvm-readobj] Change -long-option to --long-option in tests. NFCFangrui Song2019-05-01352-449/+449
| | | | | | | | | | We use both -long-option and --long-option in tests. Switch to --long-option for consistency. In the "llvm-readelf" mode, -long-option is discouraged as it conflicts with grouped short options and it is not accepted by GNU readelf. While updating the tests, change llvm-readobj -s to llvm-readobj -S to reduce confusion ("s" is --section-headers in llvm-readobj but --symbols in llvm-readelf). llvm-svn: 359649
* [AMDGPU] gfx1010 VMEM and SMEM implementationStanislav Mekhanoshin2019-04-303-1/+398
| | | | | | Differential Revision: https://reviews.llvm.org/D61330 llvm-svn: 359621
* [WebAssembly] Fix test after r359602Dan Gohman2019-04-301-1/+1
| | | | | | | Update the expected output for this test now that the EXPLICIT_NAME flag is being printed. llvm-svn: 359605
* [AArch64][SVE] Asm: add aliases for unpredicated bitwise logical instructionsCullen Rhodes2019-04-294-0/+106
| | | | | | | | | This patch adds aliases for element sizes .B/.H/.S to the AND/ORR/EOR/BIC bitwise logical instructions. The assembler now accepts these instructions with all element sizes up to 64-bit (.D). The preferred disassembly is .D. llvm-svn: 359457
* [X86] Remove some intel syntax aliases on (v)cvtpd2(u)dq, (v)cvtpd2ps, ↵Craig Topper2019-04-294-160/+2925
| | | | | | | | | | | | | | | | | | | (v)cvt(u)qq2ps. Add 'x' and'y' suffix aliases to masked version of the same in att syntax. The 128/256 bit version of these instructions require an 'x' or 'y' suffix to disambiguate the memory form in att syntax. We were allowing the same suffix in intel syntax, but it appears gas does not do that. gas does allow the 'x' and 'y' suffix on register and broadcast forms even though its not needed. We were allowing it on unmasked register form, but not on masked versions or on masked or unmasked broadcast form. While there fix some test coverage holes so they can be extended with the 'x' and 'y' suffix tests. llvm-svn: 359418
* [llvm-nm][llvm-readelf] Avoid single-dash -long-option in testsFangrui Song2019-04-271-3/+2
| | | | llvm-svn: 359383
* [AMDGPU] gfx1010 VOPC implementationStanislav Mekhanoshin2019-04-261-3/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D61208 llvm-svn: 359358
* [AMDGPU] gfx1010 VOP3 and VOP3P implementationStanislav Mekhanoshin2019-04-261-2/+11
| | | | | | Differential Revision: https://reviews.llvm.org/D61202 llvm-svn: 359328
* [AMDGPU] gfx1010 VOP2 changesStanislav Mekhanoshin2019-04-261-0/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D61156 llvm-svn: 359316
* [AMDGPU] gfx1010 SOP instructionsStanislav Mekhanoshin2019-04-247-29/+250
| | | | | | Differential Revision: https://reviews.llvm.org/D61080 llvm-svn: 359139
* [AMDGPU] gfx1010 sgpr register changesStanislav Mekhanoshin2019-04-241-2/+15
| | | | | | Differential Revision: https://reviews.llvm.org/D61045 llvm-svn: 359117
* [RISCV] Support assembling %tls_{ie,gd}_pcrel_hi modifiersLewis Revill2019-04-232-6/+38
| | | | | | | | | This patch adds support for parsing and assembling the %tls_ie_pcrel_hi and %tls_gd_pcrel_hi modifiers. Differential Revision: https://reviews.llvm.org/D55342 llvm-svn: 358994
* ARM: disallow add/sub to sp unless Rn is also sp.Tim Northover2019-04-232-0/+51
| | | | | | | | The manual says that Thumb2 add/sub instructions are only allowed to modify sp if the first source is also sp. This is slightly different from the usual rGPR restriction since it's context-sensitive, so implement it in C++. llvm-svn: 358987
* [llvm-mc] - Properly set the the address align field of the compressed sections.George Rimar2019-04-231-3/+15
| | | | | | | | | | | | | | | | | | | | | About the compressed sections spec says: (https://docs.oracle.com/cd/E37838_01/html/E36783/section_compression.html) sh_addralign fields of the section header for a compressed section reflect the requirements of the compressed section. Currently, llvm-mc always puts uncompressed section alignment to sh_addralign. It is not correct. zlib styled section contains an Elfxx_Chdr header, so we should either use 4 or 8 values depending on the target (Uncompressed section alignment is stored in ch_addralign field of the compression header). GNU assembler version 2.31.1 also has this issue, but in 2.32.51 it was already fixed. This is how it was found during debugging of the https://bugs.llvm.org/show_bug.cgi?id=40482 actually. Differential revision: https://reviews.llvm.org/D60965 llvm-svn: 358960
* [AMDGPU][MC] Corrected parsing of SP3 'neg' modifierDmitry Preobrazhensky2019-04-222-1/+29
| | | | | | | | | | See bug 41156: https://bugs.llvm.org/show_bug.cgi?id=41156 Reviewers: artem.tamazov, arsenm Differential Revision: https://reviews.llvm.org/D60624 llvm-svn: 358888
* [llvm] Prevent duplicate files in debug line header in dwarf 5: another attemptAli Tamur2019-04-193-12/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Another attempt to land the changes in debug line header to prevent duplicate files in Dwarf 5. I rolled back my previous commit because of a mistake in generating the object file in a test. Meanwhile, I addressed some offline comments and changed the implementation; the largest difference is that MCDwarfLineTableHeader does not keep DwarfVersion but gets it as a parameter. I also merged the patch to fix two lld tests that will strt to fail into this patch. Original Commit: https://reviews.llvm.org/D59515 Original Message: Motivation: In previous dwarf versions, file name indexes started from 1, and the primary source file was not explicit. Dwarf 5 standard (6.2.4) prescribes the primary source file to be explicitly given an entry with an index number 0. The current implementation honors the specification by just duplicating the main source file, once with index number 0, and later maybe with another index number. While this is compliant with the letter of the standard, the duplication causes problems for consumers of this information such as lldb. (Some files are duplicated, where only some of them have a line table although all refer to the same file) With this change, dwarf 5 debug line section files always start from 0, and the zeroth entry is not duplicated whenever possible. This requires different handling of dwarf 4 and dwarf 5 during generation (e.g. when a function returns an index zero for a file name, it signals an error in dwarf 4, but not in dwarf 5) However, I think the minor complication is worth it, because it enables all consumers (lldb, gdb, dwarfdump, objdump, and so on) to treat all files in the file name list homogenously. llvm-svn: 358732
* [AMDGPU][MC] Corrected handling of "-" before expressionsDmitry Preobrazhensky2019-04-171-1/+16
| | | | | | | | | | See bug 41156: https://bugs.llvm.org/show_bug.cgi?id=41156 Reviewers: artem.tamazov, arsenm Differential Revision: https://reviews.llvm.org/D60622 llvm-svn: 358596
* [AMDGPU][MC] Corrected parsing of registersDmitry Preobrazhensky2019-04-172-1/+65
| | | | | | | | | | See bug 41280: https://bugs.llvm.org/show_bug.cgi?id=41280 Reviewers: artem.tamazov, arsenm Differential Revision: https://reviews.llvm.org/D60621 llvm-svn: 358581
* Add slbfee instruction.Sean Fertile2019-04-151-0/+4
| | | | llvm-svn: 358425
* [WebAssembly] Add DataCount section to object filesThomas Lively2019-04-1213-33/+47
| | | | | | | | | | | | | | | | | | | Summary: This ensures that object files will continue to validate as WebAssembly modules in the presence of bulk memory operations. Engines that don't support bulk memory operations will not recognize the DataCount section and will report validation errors, but that's ok because object files aren't supposed to be run directly anyway. Reviewers: aheejin, dschuff, sbc100 Subscribers: jgravelle-google, hiraditya, sunfish, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60623 llvm-svn: 358315
* [RISCV] Diagnose invalid second input register operand when using %tprel_addRoger Ferrer Ibanez2019-04-111-0/+1
| | | | | | | | | | | | | | | | | | | RISCVMCCodeEmitter::expandAddTPRel asserts that the second operand must be x4/tp. As we are not currently checking this in the RISCVAsmParser, the assert is easy to trigger due to wrong assembly input. This patch does a late check of this constraint. An alternative could be using a singleton register class for x4/tp similar to the current one for sp. Unfortunately it does not result in a good diagnostic. Because add is an overloaded mnemonic, if no matching is possible, the diagnostic of the first failing alternative seems to be used as the diagnostic itself. This means that this case the %tprel_add is diagnosed as an invalid operand (because the real add instruction only has 3 operands). Differential Revision: https://reviews.llvm.org/D60528 llvm-svn: 358183
* [X86] Move the 2 byte VEX optimization for MOV instructions back to the ↵Craig Topper2019-04-101-0/+104
| | | | | | | | X86AsmParser::processInstruction where it used to be. Block when {vex3} prefix is present. Years ago I moved this to an InstAlias using VR128H/VR128L. But now that we support {vex3} pseudo prefix, we need to block the optimization when it is set to match gas behavior. llvm-svn: 358046
* [X86] Support the EVEX versions vcvt(t)ss2si and vcvt(t)sd2si with the ↵Craig Topper2019-04-101-88/+88
| | | | | | | | | | | | {evex} pseudo prefix in the assembler. The EVEX versions are ambiguous with the VEX versions based on operands alone so we had explicitly dropped them from the AsmMatcher table. Unfortunately, when we add them they incorrectly show in the table before their VEX counterparts. This is different how the prioritization normally works. To fix this we have to explicitly reject the instructions unless the {evex} prefix has been seen. llvm-svn: 358041
* [X86] Add support for {vex2}, {vex3}, and {evex} to the assembler to match ↵Craig Topper2019-04-093-696/+712
| | | | | | | | | | | | | | | | gas. Use {evex} to improve the one our 32-bit AVX512 tests. These can be used to force the encoding used for instructions. {vex2} will fail if the instruction is not VEX encoded, but otherwise won't do anything since we prefer vex2 when possible. Might need to skip use of the _REV MOV instructions for this too, but I haven't done that yet. {vex3} will force the instruction to use the 3 byte VEX encoding or fail if there is no VEX form. {evex} will force the instruction to use the EVEX version or fail if there is no EVEX version. Differential Revision: https://reviews.llvm.org/D59266 llvm-svn: 358029
* [WebAssembly] Add new explicit relocation types for PIC relocationsSam Clegg2019-04-041-2/+91
| | | | | | | | See https://github.com/WebAssembly/tool-conventions/pull/106 Differential Revision: https://reviews.llvm.org/D59907 llvm-svn: 357710
* [RISCV] Support assembling TLS add and associated modifiersLewis Revill2019-04-046-23/+61
| | | | | | | | | | This patch adds support in the MC layer for parsing and assembling the 4-operand add instruction needed for TLS addressing. This also involves parsing the %tprel_hi, %tprel_lo and %tprel_add operand modifiers. Differential Revision: https://reviews.llvm.org/D55341 llvm-svn: 357698
* [AArch64][AsmParser] Fix .arch_extension directive parsingSander de Smalen2019-04-046-12/+154
| | | | | | | | | | | | | | | | | | This patch fixes .arch_extension directive parsing to handle a wider range of architecture extension options. The existing parser was parsing extensions as an identifier which breaks for extensions containing a "-", such as the "tlb-rmi" extension. The extension is now parsed as a string. This is consistent with the extension parsing in the .arch and .cpu directive parsing. Patch by Cullen Rhodes (c-rhodes) Reviewed By: SjoerdMeijer Differential Revision: https://reviews.llvm.org/D60118 llvm-svn: 357677
* [AArch64] Update v8.5a MTE LDG/STG instructionsJaved Absar2019-04-033-272/+468
| | | | | | | | | | | | | The latest MTE specification adds register Xt to the STG instruction family: STG [Xn, #offset] -> STG Xt, [Xn, #offset] The tag written to memory is taken from Xt rather than Xn. Also, the LDG instruction also was changed to read return address from Xt: LDG Xt, [Xn, #offset]. This patch includes those changes and tests. Specification is at: https://developer.arm.com/docs/ddi0596/c Differential Revision: https://reviews.llvm.org/D60188 llvm-svn: 357583
* [PowerPC] Fix reversed bit issue in DCMX mask for "xvtstdcdp" and ↵Stefan Pintilie2019-04-022-0/+13
| | | | | | | | | | | | | | | | "xvtstdcsp" P9 implementation Did experiments on power 9 machine, checked the outputs for NaN & Infinity+ cases with corresponding DCMX bit set. Confirmed the DCMX mask bit for NaN and infinity+ are reversed. This patch fixes the issue. Patch by Victor Huang. Differential Revision: https://reviews.llvm.org/D59384 llvm-svn: 357494
* [RISCV] Support assembling @plt symbol operandsAlex Bradbury2019-04-023-0/+15
| | | | | | | | | | This patch allows symbols appended with @plt to parse and assemble with the R_RISCV_CALL_PLT relocation. Differential Revision: https://reviews.llvm.org/D55335 Patch by Lewis Revill. llvm-svn: 357470
* [AArch64] Add v8.5-a Memory Tagging STZGM instructionDavid Spickett2019-04-013-0/+49
| | | | | | | | | | | | | | | This instruction writes a block of allocation tags and stores zero to the associated data locations. It differs from STGM by 1 bit and has the same arguments. The specification can be found here: https://developer.arm.com/docs/ddi0596/c Differential Revision: https://reviews.llvm.org/D60065 llvm-svn: 357397
* [AArch64] Add v8.5-a Memory Tagging STGM/LDGM instructionsDavid Spickett2019-04-014-62/+46
| | | | | | | | | | | | | | The STGV/LDGV instructions were replaced with STGM/LDGM. The encodings remain the same but there is no longer writeback so there are no unpredictable encodings to check for. The specfication can be found here: https://developer.arm.com/docs/ddi0596/c Differential Revision: https://reviews.llvm.org/D60064 llvm-svn: 357395
* [AArch64] Add v8.5-a Memory Tagging GMID_EL1 registerDavid Spickett2019-04-013-0/+31
| | | | | | | | | | | The latest version of the MTE spec added a system register 'GMID_EL1'. It contains the block size used by the LDGM and STGM instructions and is read only. The specification can be found here: https://developer.arm.com/docs/ddi0596/c llvm-svn: 357392
* [RISCV] Don't evaluatePCRelLo if a relocation will be forced (e.g. due to ↵Alex Bradbury2019-04-012-6/+8
| | | | | | | | | | | | | | | | | | linker relaxation) A pcrel_lo will point to the associated pcrel_hi fixup which in turn points to the real target. RISCVMCExpr::evaluatePCRelLo will work around this indirection in order to allow the fixup to be evaluate properly. However, if relocations are forced (e.g. due to linker relaxation is enabled) then its evaluation is undesired and will result in a relocation with the wrong target. This patch modifies evaluatePCRelLo so it will not try to evaluate if the fixup will be forced as a relocation. A new helper method is added to RISCVAsmBackend to query this. Differential Revision: https://reviews.llvm.org/D59686 llvm-svn: 357374
* [AMDGPU][MC] Corrected conversion rules for inlinable constants to match ↵Dmitry Preobrazhensky2019-03-293-19/+72
| | | | | | | | | | | | rules for literals See bug 40806: https://bugs.llvm.org/show_bug.cgi?id=40806 Reviewers: artem.tamazov, arsenm Differential Revision: https://reviews.llvm.org/D59786 llvm-svn: 357262
* [AMDGPU][MC] Corrected handling of tied src for atomic return MUBUF opcodesDmitry Preobrazhensky2019-03-291-0/+8
| | | | | | | | | | See bug 40917: https://bugs.llvm.org/show_bug.cgi?id=40917 Reviewers: artem.tamazov, arsenm Differential Revision: https://reviews.llvm.org/D59878 llvm-svn: 357249
* [WebAssembly] Merge used feature sets, update atomics linkage policyThomas Lively2019-03-2910-51/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: It does not currently make sense to use WebAssembly features in some functions but not others, so this CL adds an IR pass that takes the union of all used feature sets and applies it to each function in the module. This allows us to prevent atomics from being lowered away if some function has opted in to using them. When atomics is not enabled anywhere, we detect whether there exists any atomic operations or thread local storage that would be stripped and disallow linking with objects that contain atomics if and only if atomics or tls are stripped. When atomics is enabled, mark it as used but do not require it of other objects in the link. These changes allow libraries that do not use atomics to be built once and linked into both single-threaded and multithreaded binaries. Reviewers: aheejin, sbc100, dschuff Subscribers: jgravelle-google, hiraditya, sunfish, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59625 llvm-svn: 357226
* [MC] Fix floating-point literal lexing.Eli Friedman2019-03-281-4/+43
| | | | | | | | | | | | | | | | | | | | | This patch has three related fixes to improve float literal lexing: 1. Make AsmLexer::LexDigit handle floats without a decimal point more consistently. 2. Make AsmLexer::LexFloatLiteral print an error for floats which are apparently missing an "e". 3. Make APFloat::convertFromString use binutils-compatible exponent parsing. Together, this fixes some cases where a float would be incorrectly rejected, fixes some cases where the compiler would crash, and improves diagnostics in some cases. Patch by Brandon Jones. Differential Revision: https://reviews.llvm.org/D57321 llvm-svn: 357214
OpenPOWER on IntegriCloud