summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target
Commit message (Collapse)AuthorAgeFilesLines
* [X86][CET] Shadow stack fix for setjmp/longjmpAlexander Ivchenko2018-06-052-5/+257
| | | | | | | | | | | | | | | This is the new version of D46181, allowing setjmp/longjmp to work correctly with the Intel CET shadow stack by storing SSP on setjmp and fixing it on longjmp. The patch has been updated to use the cf-protection-return module flag instead of HasSHSTK, and the bug that caused D46181 to be reverted has been fixed with the test expanded to track that fix. patch by mike.dvoretsky Differential Revision: https://reviews.llvm.org/D47311 llvm-svn: 333990
* [X86] Make all instructions that operate on MMX types, but were added after ↵Craig Topper2018-06-052-18/+18
| | | | | | | | the initial MMX support via one of the SSE features flags make them require the MMX feature as well. Passing -mattr=-mmx needs to disable these instructions since the MMX register class won't have been set up. But we don't want -mattr=-mmx to disable SSE so we have to do it separately. llvm-svn: 333984
* Simplified WebAssemblyAsmBackend by removing explicit ELF variant.Derek Schuff2018-06-041-82/+8
| | | | | | | | | | | | | The ELF version was broken (does not deal with wasm specific fixups), and now is slightly less broken. It will be removed in its entirety in the future which this change makes slightly easier (just remove the IsELF bool). Differential Revision: https://reviews.llvm.org/D47745 Patch by Wouter van Oortmerssen llvm-svn: 333964
* Move Analysis/Utils/Local.h back to TransformsDavid Blaikie2018-06-046-6/+6
| | | | | | | | | | Review feedback from r328165. Split out just the one function from the file that's used by Analysis. (As chandlerc pointed out, the original change only moved the header and not the implementation anyway - which was fine for the one function that was used (since it's a template/inlined in the header) but not in general) llvm-svn: 333954
* [MachineOutliner] NFC - Move intermediate data structures to MachineOutliner.hJessica Paquette2018-06-044-88/+81
| | | | | | | | | | | | | | | | | | | | | This is setting up to fix bug 37573 cleanly. This moves data structures that are technically both used in some way by the target and the general-purpose outlining algorithm into MachineOutliner.h. In particular, the `Candidate` class is of importance. Before, the outliner passed the locations of `Candidates` to the target, which would then make some decisions about the prospective outlined function. This change allows us to just pass `Candidates` along to the target. This will allow the target to discard `Candidates` that would be considered unsafe before cost calculation. Thus, we will be able to remove the unsafe candidates described in the bug without resorting to torching the entire prospective function. Also, as a side-effect, it makes the outliner a bit cleaner. https://bugs.llvm.org/show_bug.cgi?id=37573 llvm-svn: 333952
* [X86][ELF][CET] Adding the .note.gnu.property ELF section in X86Alexander Ivchenko2018-06-041-0/+38
| | | | | | | | | | | | | | In preparation for the proposed linker ABI changes (https://github.com/hjl-tools/linux-abi/wiki/linux-abi-draft.pdf, https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-cet.pdf), this patch enables emission of the .note.gnu.property section to ELF object files when building CET-enabled modules. patch by mike.dvoretsky Differential Revision: https://reviews.llvm.org/D47145 llvm-svn: 333951
* [X86] Don't pass ParitySrc array into isAddSubOrSubAddMask. Instead use a ↵Craig Topper2018-06-041-8/+10
| | | | | | | | bool output parameter to get the real piece of info we care about. NFC The ParitySrc array is more of an implementation detail. A single bool to get the final parity is sufficient. llvm-svn: 333935
* [AMDGPU] Small refactoring in the schedulerStanislav Mekhanoshin2018-06-041-18/+3
| | | | | | | | After last changes some code can be simplified. Differential Revision: https://reviews.llvm.org/D47661 llvm-svn: 333934
* [AMDGPU] Factored out common part of GCNRPTracker::reset()Stanislav Mekhanoshin2018-06-042-11/+17
| | | | | | Differential Revision: https://reviews.llvm.org/D47664 llvm-svn: 333931
* [WebAssembly] Fix .td files after rL333900Sam Clegg2018-06-043-33/+33
| | | | | | Differential Revision: https://reviews.llvm.org/D47727 llvm-svn: 333928
* [AMDGPU][Waitcnt] Fix handling of flat instrsMark Searles2018-06-042-6/+14
| | | | | | | | On GFX9 and earlier, flat memory ops may decrement VMCNT out-of-order as well as LGKMCNT out-of-order. Differential Revision: https://reviews.llvm.org/D46616 llvm-svn: 333926
* [X86] Only accept const SelectionDAG to ↵Simon Pilgrim2018-06-041-2/+2
| | | | | | | | resolveTargetShuffleInputs/getFauxShuffleMask These methods should only be using SelectionDAG for analysis (known/sign bits etc), not node creation. llvm-svn: 333925
* [NVPTX] Delete dead code from the AsmPrinter.Benjamin Kramer2018-06-042-142/+0
| | | | llvm-svn: 333924
* [RFC][patch 3/3] Add support for variant scheduling classes in llvm-mca.Andrea Di Biagio2018-06-042-1/+37
| | | | | | | | | | | | | | | | | | | | | | | | This patch is the last of a sequence of three patches related to LLVM-dev RFC "MC support for variant scheduling classes". http://lists.llvm.org/pipermail/llvm-dev/2018-May/123181.html This fixes PR36672. The main goal of this patch is to teach llvm-mca how to solve variant scheduling classes. This patch does that, plus it adds new variant scheduling classes to the BtVer2 scheduling model to identify so-called zero-idioms (i.e. so-called dependency breaking instructions that are known to generate zero, and that are optimized out in hardware at register renaming stage). Without the BtVer2 change, this patch would not have had any meaningful tests. This patch is effectively the union of two changes: 1) a change that teaches llvm-mca how to resolve variant scheduling classes. 2) a change to the BtVer2 scheduling model that allows us to special-case packed XOR zero-idioms (this partially fixes PR36671). Differential Revision: https://reviews.llvm.org/D47374 llvm-svn: 333909
* AMDGPU: Make various NamedOperands upper caseNicolai Haehnle2018-06-044-43/+43
| | | | | | | | | | | | | | | | Summary: Avoid name clashes with the corresponding bit fields in the instruction encoding. Change-Id: Id1644e703e976e78f7af93788d9f44cb48c3251f Reviewers: arsenm, rampitec, kzhuravl Subscribers: wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D47433 llvm-svn: 333905
* TableGen: Streamline the semantics of NAMENicolai Haehnle2018-06-045-284/+298
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The new rules are straightforward. The main rules to keep in mind are: 1. NAME is an implicit template argument of class and multiclass, and will be substituted by the name of the instantiating def/defm. 2. The name of a def/defm in a multiclass must contain a reference to NAME. If such a reference is not present, it is automatically prepended. And for some additional subtleties, consider these: 3. defm with no name generates a unique name but has no special behavior otherwise. 4. def with no name generates an anonymous record, whose name is unique but undefined. In particular, the name won't contain a reference to NAME. Keeping rules 1&2 in mind should allow a predictable behavior of name resolution that is simple to follow. The old "rules" were rather surprising: sometimes (but not always), NAME would correspond to the name of the toplevel defm. They were also plain bonkers when you pushed them to their limits, as the old version of the TableGen test case shows. Having NAME correspond to the name of the toplevel defm introduces "spooky action at a distance" and breaks composability: refactoring the upper layers of a hierarchy of nested multiclass instantiations can cause unexpected breakage by changing the value of NAME at a lower level of the hierarchy. The new rules don't suffer from this problem. Some existing .td files have to be adjusted because they ended up depending on the details of the old implementation. Change-Id: I694095231565b30f563e6fd0417b41ee01a12589 Reviewers: tra, simon_tatham, craig.topper, MartinO, arsenm, javed.absar Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D47430 llvm-svn: 333900
* [mips] Restore the availablity of trap for microMIPSSimon Dardis2018-06-041-0/+1
| | | | | | | | Reviewers: smaksimovic, atanasyan, abeserminji Differential Revision: https://reviews.llvm.org/D47584 llvm-svn: 333895
* [AArch64] Audit on rL333634 to fix FP16 Disasm BitPatternsLuke Geeson2018-06-042-2/+2
| | | | llvm-svn: 333879
* [AArch64][SVE] Fix range for DUP immediates (16bit elts)Sander de Smalen2018-06-042-3/+11
| | | | | | | | | | | | | | | For immediates used in DUP instructions that have the range -128 to 127, or a multiple of 256 in the range -32768 to 32512, one could argue that when the result element size is 16bits (.h), the value can be considered both signed and unsigned. Reviewers: rengolin, fhahn, SjoerdMeijer, samparker, javed.absar Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D47619 llvm-svn: 333873
* [AArch64][SVE] Asm: Print indexed element 0 as FPR.Sander de Smalen2018-06-045-0/+67
| | | | | | | | | | | | | | | | | | | | Print the first indexed element as a FP register, for example: mov z0.d, z1.d[0] Is now printed as: mov z0.d, d1 Next to printing, this patch also adds aliases to parse 'mov z0.d, d1'. Reviewers: rengolin, fhahn, samparker, SjoerdMeijer, javed.absar Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D47571 llvm-svn: 333872
* [AArch64][SVE] Asm: Support for indexed DUP instructions.Sander de Smalen2018-06-044-71/+127
| | | | | | | | | | | | | | | | | | | | Unpredicated copy of indexed SVE element to SVE vector, along with MOV-aliases. For example: dup z0.h, z1.h[0] duplicates the first 16-bit element from z1 to all elements in the result vector z0. Reviewers: rengolin, fhahn, samparker, SjoerdMeijer, javed.absar Reviewed By: SjoerdMeijer Differential Revision: https://reviews.llvm.org/D47570 llvm-svn: 333871
* [AArch64][SVE] Asm: Support for FCPY immediate instructions.Sander de Smalen2018-06-042-2/+43
| | | | | | | | | | | | | Predicated copy of floating-point immediate value to SVE vector, along with MOV-aliases. Reviewers: rengolin, fhahn, samparker, SjoerdMeijer, javed.absar Reviewed By: javed.absar Differential Revision: https://reviews.llvm.org/D47518 llvm-svn: 333869
* [AArch64][SVE] Asm: Support for CPY immediate instructionsSander de Smalen2018-06-042-0/+62
| | | | | | | | | | | | | Predicated copy of possibly shifted immediate value into SVE vector, along with MOV-aliases. Reviewers: rengolin, fhahn, samparker, SjoerdMeijer, javed.absar Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D47517 llvm-svn: 333868
* [X86] Remove and autoupgrade masked avx512vnni intrinsics using the unmasked ↵Craig Topper2018-06-031-26/+0
| | | | | | intrinsics and select instructions. llvm-svn: 333857
* Remove SETCCE use from Lanai's backendAmaury Sechet2018-06-032-17/+0
| | | | | | | | | | | | Summary: This creates a small perf regression, but after talking with Jacques Pienaar, he was good with it to get things moving toward removng SETCCE. Reviewers: jpienaar, bryant Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47626 llvm-svn: 333838
* [NEON] Support VLD1xN intrinsics in AArch32 mode (LLVM part)Ivan A. Kosarev2018-06-025-7/+202
| | | | | | | | | We currently support them only in AArch64. The NEON Reference, however, says they are 'ARMv7, ARMv8' intrinsics. Differential Revision: https://reviews.llvm.org/D47120 llvm-svn: 333825
* Revert r333819 "[NEON] Support VLD1xN intrinsics in AArch32 mode (Clang part)"Ivan A. Kosarev2018-06-025-202/+7
| | | | | | | | The LLVM part was committed instead of the Clang part. Differential Revision: https://reviews.llvm.org/D47121 llvm-svn: 333824
* [X86] Add tied source operand to AVX5124FMAPS and AVX5124VNNIW instructions.Craig Topper2018-06-021-20/+33
| | | | | | This doesn't affect the assembly or disassembly, but is more accurate. llvm-svn: 333822
* [X86] Fix warning message for AVX5124FMAPS and AVX5124VNNIW instructions in ↵Craig Topper2018-06-021-2/+2
| | | | | | | | the assembly parser. The caret was positioned on the wrong operand. It's too hard to get right so just put the caret at the beginning of the instruction. llvm-svn: 333821
* [NEON] Support VLD1xN intrinsics in AArch32 mode (Clang part)Ivan A. Kosarev2018-06-025-7/+202
| | | | | | | | | We currently support them only in AArch64. The NEON Reference, however, says they are 'ARMv7, ARMv8' intrinsics. Differential Revision: https://reviews.llvm.org/D47121 llvm-svn: 333819
* [X86] Add encoding information for the AVX5124FMAPS and AVX5124VNNIW ↵Craig Topper2018-06-023-1/+78
| | | | | | | | | | 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] Do something sensible when an expand load intrinsic is passed a 0 mask.Craig Topper2018-06-011-1/+1
| | | | | | Previously we just returned undef, but really we should be returning the pass thru input. We also need to make sure we preserve the chain output that the original intrinsic node had to maintain connectivity in the DAG. So we should just return the incoming chain as the output chain. llvm-svn: 333804
* [X86] Add isel patterns to use vexpand with zero masking when the passthru ↵Craig Topper2018-06-011-0/+4
| | | | | | value is a zero vector. llvm-svn: 333800
* [mips] Support 64-bit offsets for lb/sb/ld/sd/lld ... instructionsSimon Atanasyan2018-06-011-53/+30
| | | | | | | | | | | | | | | The `MipsAsmParser::loadImmediate` can load immediates of various sizes into a register. Idea of this change is to use `loadImmediate` in the `MipsAsmParser::expandMemInst` method to load offset into a register and then call required load/store instruction. The patch removes separate `expandLoadInst` and `expandStoreInst` methods and does everything in the `expandMemInst` method to escape code duplication. Differential Revision: https://reviews.llvm.org/D47316 llvm-svn: 333774
* [mips] Extend list of relocations supported by the `.reloc` directiveSimon Atanasyan2018-06-013-1/+80
| | | | | | | Supporting GOT and TLS related relocations by the `.reloc` directive is useful for purpose of testing various tools like a linker, for example. llvm-svn: 333773
* [Hexagon] Avoid UB when shifting unsigned integer left by 32Krzysztof Parzyszek2018-06-011-3/+4
| | | | llvm-svn: 333771
* [Hexagon] Select HVX code for vector CTPOP, CTLZ, and CTTZKrzysztof Parzyszek2018-06-013-15/+80
| | | | llvm-svn: 333760
* [NFC] Zero initialize local variablesHiroshi Inoue2018-06-011-1/+1
| | | | | | This patch makes local variables zero initialized to avoid broken values in debug output. llvm-svn: 333754
* [SelectionDAG] Expand UADDO/USUBO into ADD/SUBCARRY if legal for targetKrzysztof Parzyszek2018-06-014-5/+48
| | | | | | | | | Additionally, implement handling of ADD/SUBCARRY on Hexagon, utilizing the UADDO/USUBO expansion. Differential Revision: https://reviews.llvm.org/D47559 llvm-svn: 333751
* Set ADDE/ADDC/SUBE/SUBC to expand by defaultAmaury Sechet2018-06-0110-59/+26
| | | | | | | | | | | | | | | Summary: They've been deprecated in favor of UADDO/ADDCARRY or USUBO/SUBCARRY for a while. Target that uses these opcodes are changed in order to ensure their behavior doesn't change. Reviewers: efriedma, craig.topper, dblaikie, bkramer Subscribers: jholewinski, arsenm, jyknight, sdardis, nemanjai, nhaehnle, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, mgrang, atanasyan, llvm-commits Differential Revision: https://reviews.llvm.org/D47422 llvm-svn: 333748
* [AArch64][GlobalISel] Zero-extend s1 values when returning.Amara Emerson2018-06-011-1/+6
| | | | | | | | | | | Before we were relying on the any extend of the s1 to s32, but for AAPCS we need to zero-extend it to at least s8. Fixes PR36719 Differential Revision: https://reviews.llvm.org/D47425 llvm-svn: 333747
* [AArch64][SVE] Asm: Support for FDUP_ZI (copy fp immediate) instruction.Sander de Smalen2018-06-012-0/+39
| | | | | | | | | | | | | Unpredicated copy of floating-point immediate value into SVE vector, along with MOV-aliases. Reviewers: rengolin, fhahn, samparker, SjoerdMeijer, javed.absar Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D47482 llvm-svn: 333744
* [mips] Guard more aliases correctly.Simon Dardis2018-06-012-48/+56
| | | | | | Also, duplicate an alias for microMIPS. llvm-svn: 333741
* [mips] Guard 'nop' properly and add mips16's nop instructionSimon Dardis2018-06-013-12/+19
| | | | | | | | Reviewers: smaksimovic, atanasyan, abeserminji Differential Revision: https://reviews.llvm.org/D47583 llvm-svn: 333739
* [mips] Select the correct instruction for computing frameindexesSimon Dardis2018-06-014-3/+7
| | | | | | | | Reviewers: smaksimovic, atanasyan, abeserminji Differential Revision: https://reviews.llvm.org/D47582 llvm-svn: 333736
* [AArch64][SVE] Asm: Support for DUPM (masked immediate) instruction.Sander de Smalen2018-06-017-1/+137
| | | | | | | | | | | | | Unpredicated copy of repeating immediate pattern to SVE vector, along with MOV-aliases. Reviewers: rengolin, fhahn, samparker, SjoerdMeijer, javed.absar Reviewed By: SjoerdMeijer Differential Revision: https://reviews.llvm.org/D47328 llvm-svn: 333731
* [X86][Disassembler] Make it an error to set EVEX.R' to 0 when modrm.reg ↵Craig Topper2018-06-011-7/+18
| | | | | | | | encodes a GPR. This is different than the behavior of EVEX.X extending modrm.rm to 5 bits. llvm-svn: 333728
* [X86][Disassembler] Ignore EVEX.X extension of modrm.rm to 5-bits when ↵Craig Topper2018-06-011-0/+1
| | | | | | modrm.rm encodes a k-register. llvm-svn: 333727
* [X86][Disassembler] Clamp index to 4-bits when decoding GPR registers.Craig Topper2018-06-011-3/+4
| | | | | | A 5-bit value can occur when EVEX.X is 0 due to it being used to extend modrm.rm to encode XMM16-31. But if modrm.rm instead encodes a GPR, the Intel documentation says EVEX.X should be ignored so just mask it to 4 bits once we know its a GPR. llvm-svn: 333725
* [X86][Disassembler] Make sure EVEX.X is not used to extend base registers of ↵Craig Topper2018-06-011-3/+5
| | | | | | | | | | memory operations. This was an accidental side effect of EVEX.X being used to encode XMM16-XMM31 using modrm.rm with modrm.mod==0x3. I think there are still more bugs related to this. llvm-svn: 333722
OpenPOWER on IntegriCloud