summaryrefslogtreecommitdiffstats
path: root/llvm
Commit message (Collapse)AuthorAgeFilesLines
* Object: Move some code from ELF.h into ELF.cpp.Peter Collingbourne2017-10-312-263/+263
| | | | | | Differential Revision: https://reviews.llvm.org/D39271 llvm-svn: 317046
* Inline compareAddr function into its only caller. NFCI.Peter Collingbourne2017-10-312-7/+5
| | | | llvm-svn: 317045
* Revert r317040: [globalisel][tablegen] Keep track of the insertion point ↵Daniel Sanders2017-10-311-77/+33
| | | | | | | | | | while adding BuildMIAction's. NFC The same bots fail but I believe I know what the issue is now. These bots are missing the const_iterator versions of insert/emplace/etc. that were introduced in C++11. llvm-svn: 317042
* [codeview] Merge file checksum entries for DIFiles with the same absolute pathReid Kleckner2017-10-313-4/+112
| | | | | | | | Change the map key from DIFile* to the absolute path string. Computing the absolute path isn't expensive because we already have a map that caches the full path keyed on DIFile*. llvm-svn: 317041
* Re-commit: [globalisel][tablegen] Keep track of the insertion point while ↵Daniel Sanders2017-10-311-33/+77
| | | | | | | | | | | | | | | | | | | adding BuildMIAction's. NFC Multi-instruction emission needs to ensure the the instructions are generated a depth-first fashion. For example: (ADDWrr (SUBWrr a, b), c) needs to emit the SUBWrr before the ADDWrr. However, our walk over TreePatternNode's is highly context sensitive which makes it difficult to append BuildMIActions in the order we want. To fix this, we now keep track of the insertion point as we add actions. This will allow multi-insn emission to insert BuildMI's in the correct place. The previous commit failed on the Ubuntu bots using GCC 4.8. These bots didn't like a call to emplace(). I've replaced it with insert() to see if it's a quirk of the C++11 support. llvm-svn: 317040
* AMDGPU: Select s_buffer_load_dword with a non-constant SGPR offsetMarek Olsak2017-10-315-17/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Apps that benefit: - alien isolation - bioshock infinite - civilization: beyond earth - company of heroes 2 - dirt showdown - dota 2 - F1 2015 - grid autosport - hitman - legend of grimrock - serious sam 3: bfe - shadow warrior - talos principle - total war: warhammer - UE4 demos: effects cave, elemental, sun temple Reviewers: arsenm, nhaehnle Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, llvm-commits, t-tye Differential Revision: https://reviews.llvm.org/D38914 llvm-svn: 317038
* loop-rotate: simplify code by using llvm::findDbgValues(). (NFC)Adrian Prantl2017-10-311-31/+23
| | | | llvm-svn: 317037
* Revert r317029: [globalisel][tablegen] Keep track of the insertion point ↵Daniel Sanders2017-10-311-77/+33
| | | | | | | | while adding BuildMIAction's. NFC The Linux bots don't seem to like this usage of emplace(). Reverting while I look into it. llvm-svn: 317033
* Revert "[DWARF] Now that Optional is standard layout, put it into an union ↵Benjamin Kramer2017-10-312-6/+13
| | | | | | | | instead of splatting it." GCC doesn't like it. This reverts commit r317028. llvm-svn: 317030
* [globalisel][tablegen] Keep track of the insertion point while adding ↵Daniel Sanders2017-10-311-33/+77
| | | | | | | | | | | | | | | BuildMIAction's. NFC Multi-instruction emission needs to ensure the the instructions are generated a depth-first fashion. For example: (ADDWrr (SUBWrr a, b), c) needs to emit the SUBWrr before the ADDWrr. However, our walk over TreePatternNode's is highly context sensitive which makes it difficult to append BuildMIActions in the order we want. To fix this, we now keep track of the insertion point as we add actions. This will allow multi-insn emission to insert BuildMI's in the correct place. llvm-svn: 317029
* [DWARF] Now that Optional is standard layout, put it into an union instead ↵Benjamin Kramer2017-10-312-13/+6
| | | | | | | | of splatting it. No functionality change intended. llvm-svn: 317028
* [coro] Make Spill a proper struct instead of deriving from pair.Benjamin Kramer2017-10-311-12/+10
| | | | | | No functionality change. llvm-svn: 317027
* [globalisel][tablegen] Factor out implicit def/use renderers from ↵Daniel Sanders2017-10-311-12/+48
| | | | | | | | | | | | createAndImportInstructionRenderer(). NFC Multi-instruction emission will require that we have separate handling for the defs between the implicitly created temporaries and the rule outputs. The former require new temporary vregs while the latter should copy existing operands. Factor out the implicit def/use renderers to minimize the code duplication when we implement that. llvm-svn: 317025
* [SimplifyCFG] Use a more generic name for the selects created by ↵Craig Topper2017-10-311-2/+2
| | | | | | | | | | | | SpeculativelyExecuteBB to prevent long names from being created Currently the selects are created with the names of their inputs concatenated together. It's possible to get cases that chain these selects together resulting in long names due to multiple levels of concatenation. Our internal branch of llvm managed to generate names over 100000 characters in length on a particular test due to an extreme compounding of the names. This patch changes the name to a generic name that is not dependent on its inputs. Differential Revision: https://reviews.llvm.org/D39440 llvm-svn: 317024
* [SimplifyCFG] Regenerate some test cases using update_test_checks.py to ↵Craig Topper2017-10-315-91/+259
| | | | | | | | prepare for an upcoming commit. NFC A future commit will change how some of the value names in the IR are generated which causes these tests to break in their current form. The script generates checks with regular expressions so it should be immune. llvm-svn: 317023
* [globalisel][tablegen] Add infrastructure to potentially allow BuildMIAction ↵Daniel Sanders2017-10-311-43/+73
| | | | | | | | | | | | | | | | | | to choose a mutatable instruction. NFC Prepare for multiple instruction emission by allowing BuildMIAction to search for a suitable matcher that will support mutation. This patch deliberately neglects to add matchers aside from the root to preserve NFC. That said, it should be noted that until we support mutations other than just the opcode the chances of finding a non-root instruction for which canMutate() is true, is essentially zero. Furthermore in the presence of multi-instruction emission the chances of finding any instruction for which canMutate() is true is also zero. Nevertheless, we can't continue to require that all BuildMIAction's consider the root of the match to be recyclable due to the risk of recycling it twice in the same rule. llvm-svn: 317022
* [X86][AVX512] Regenerate tests to remove retl/retq regexSimon Pilgrim2017-10-313-107/+107
| | | | | | These are only testing 64-bit targets so we don't need the regex llvm-svn: 317021
* [X86][AVX512] Split AVX512F and AVX512BW bool-vector bitcast testsSimon Pilgrim2017-10-314-342/+799
| | | | llvm-svn: 317020
* [ADT] Split optional to only include copy mechanics and dtor for non-trivial ↵Benjamin Kramer2017-10-312-58/+117
| | | | | | | | | types. This makes uses of Optional more transparent to the compiler (and clang-tidy) and generates slightly smaller code. llvm-svn: 317019
* [Metadata][NFC] Make MDNode::resolve() public in preparation for the fix to ↵Wolfgang Pieb2017-10-311-3/+3
| | | | | | | PR33930. Reviewers: aprantl llvm-svn: 317018
* [globalisel][tablegen] Allow any comment in DebugCommentAction. NFCDaniel Sanders2017-10-311-6/+6
| | | | llvm-svn: 317017
* [IndVarSimplify] Extract wrapper around SE-.isLoopInvariantPredicate [NFC]Philip Reames2017-10-311-17/+33
| | | | | | This an intermediate state, the next patch will re-inline the markLoopInvariantPredicate function to reduce code duplication. llvm-svn: 317016
* [Support] Make the default chunk size of raw_fd_ostream to 1 GiB.Rui Ueyama2017-10-311-11/+12
| | | | | | | | | | | | | | | | | | Previously, we call write(2) for each 32767 byte chunk. That is not efficient because Linux can handle much larger write requests. This patch changes the chunk size on Linux to 1 GiB. This patch also changes the default chunks size to SSIZE_MAX. I think that doesn't in practice change this function's behavior on any operating system because SSIZE_MAX on 64-bit machine is unrealistically large, and writing 2 GiB (SSIZE_MAX on 32-bit) on a 32-bit machine by a single call of write(2) is also unrealistic, as the userspace is usually limited to 2 GiB. That said, it is in general a good thing to do because a write larger than SSIZE_MAX is implementation-defined in POSIX. Differential Revision: https://reviews.llvm.org/D39444 llvm-svn: 317015
* [IndVarSimplify] Simplify code using a dictionaryPhilip Reames2017-10-311-16/+8
| | | | | | Possibly very slightly slower, but this code is not performance critical and the readability benefit alone is huge. llvm-svn: 317012
* [X86][AsmParser] Treat '%' as the modulo operator under Intel syntaxReid Kleckner2017-10-312-1/+7
| | | | | | | | | | It can't be a register prefix, anyway. This is consistent with the masm docs on MSDN: https://msdn.microsoft.com/en-us/library/t4ax90d2.aspx This is a straight-forward extension of our support for "MOD" implemented in https://reviews.llvm.org/D33876 / r306425 llvm-svn: 317011
* LTOModule::isBitcodeFile() shouldn't assert when returning false.Nico Weber2017-10-312-4/+20
| | | | | | | | | | | | Fixes a bunch of assert-on-invalid-bitcode regressions after 315483. Expected<> calls assertIsChecked() in its dtor, and operator bool() only calls setChecked() if there's no error. So for functions that don't return an error itself, the Expected<> version needs explicit code to disarm the error that the ErrorOr<> code didn't need. https://reviews.llvm.org/D39437 llvm-svn: 317010
* [asan] Upgrade private linkage globals to internal linkage on COFFReid Kleckner2017-10-312-2/+16
| | | | | | | COFF comdats require symbol table entries, which means the comdat leader cannot have private linkage. llvm-svn: 317009
* [X86][SSE] Add VSRLI/VSRAI/VSLLI demanded elts support to ↵Simon Pilgrim2017-10-311-5/+6
| | | | | | | | computeKnownBits/ComputeNumSignBits Mainly a perf improvements as most combines will have occurred before we lower to these instructions llvm-svn: 317005
* [LoopVectorize] Replace manual VPlan memory management with unique_ptr.Benjamin Kramer2017-10-311-26/+10
| | | | | | No functionality change intended. llvm-svn: 317003
* [test] Fix dsymutil/cmdline.testJonas Devlieghere2017-10-311-1/+1
| | | | | | | This fixes dsymutil/cmdline.test on platforms where the dsymutil binary has an extension. llvm-svn: 317001
* [Reassociate] Remove FIXME from looptest.ll (NFC)Florian Hahn2017-10-311-2/+3
| | | | | | | | | | | | | | Summary: The loop invariant add (i+j) is reassoicated, I think the FIXME can be removed, because this is what the test case tries to check (AFAIK). I also changed the test to use FileCheck. Reviewers: mcrosier, davide Reviewed By: mcrosier, davide Subscribers: davide, llvm-commits Differential Revision: https://reviews.llvm.org/D39424 llvm-svn: 317000
* [dsymutil] Implement the --threads optionJonas Devlieghere2017-10-313-10/+67
| | | | | | | | | | | | | | This patch adds the --threads option to dsymutil to process architectures in parallel. The feature is already present in the version distributed with Xcode, but was not yet upstreamed. This is NFC as far as the linking behavior is concerned. As threads are used automatically, the current tests cover the change in implementation. Differential revision: https://reviews.llvm.org/D39355 llvm-svn: 316999
* [ThinLTO] Double bits of module hash used for renamingTeresa Johnson2017-10-311-1/+2
| | | | | | | | | | | | | | | Summary: Use 64 instead of 32 bits of the module hash as the suffix when renaming after promotion to reduce the likelihood of a collision (which we observed in a binary when using 32 bits). Reviewers: pcc Subscribers: llvm-commits, inglorion Differential Revision: https://reviews.llvm.org/D39443 llvm-svn: 316996
* [InstCombine] Simplify selects that test cmpxchg instructionsMatthew Simpson2017-10-312-0/+115
| | | | | | | | | | If a select instruction tests the returned flag of a cmpxchg instruction and selects between the returned value of the cmpxchg instruction and its compare operand, the result of the select will always be equal to its false value. Differential Revision: https://reviews.llvm.org/D39383 llvm-svn: 316994
* Adding a shufflevector and select LLVM IR instructions fuzz toolAyman Musa2017-10-311-0/+404
| | | | | | | | | | | Based on similar python tool - utils/shuffle-fuzz.py - this tool extends the ability of it's previous by optionally attaching select instruction to the generated shufflevector instructions. This was mainly developed to perform exhaustive testing of the X86 AVX512 masked shuffle instructions. But yet it can be used for various other targets. The general design of the implementation is much modular than the original shuffle_fuzz.py tool, which makes it easier for anyone to extend it further. Differential Revision: https://reviews.llvm.org/D38031 Change-Id: I0efc2aaa091b61a8a9552311c21cc77916a97111 llvm-svn: 316989
* [LoopUnroll] Clean up remarks for unroll remainderDavid Green2017-10-314-33/+59
| | | | | | | | | | | | | | | | The optimisation remarks for loop unrolling with an unrolled remainder looks something like: test.c:7:18: remark: completely unrolled loop with 3 iterations [-Rpass=loop-unroll] C[i] += A[i*N+j]; ^ test.c:6:9: remark: unrolled loop by a factor of 4 with run-time trip count [-Rpass=loop-unroll] for(int j = 0; j < N; j++) ^ This removes the first of the two messages. Differential revision: https://reviews.llvm.org/D38725 llvm-svn: 316986
* [AVX512] Adding new patterns for extract_subvector of vXi1Michael Zuckerman2017-10-311-14/+42
| | | | | | | | | | | | | | | | | extract subvector of vXi1 from vYi1 is poorly supported by LLVM and most of the time end with an assertion. This patch fixes this issue by adding new patterns to the TD file. Reviewers: 1. guyblank 2. igorb 3. zvi 4. ayman 5. craig.topper Differential Revision: https://reviews.llvm.org/D39292 Change-Id: Ideb4d7e946c8d40cfce2920891f2d89fe64c58f8 llvm-svn: 316981
* [CGP] Fix the detection of trivial case for addressing modeSerguei Katkov2017-10-311-10/+9
| | | | | | | The address can be presented as a bitcast of baseReg. In this case it is still trivial but OriginalValue != baseReg. llvm-svn: 316980
* [IRCE][NFC] Rename fields of InductiveRangeCheckMax Kazantsev2017-10-313-25/+25
| | | | | | | | | | Rename `Offset`, `Scale`, `Length` into `Begin`, `Step`, `End` respectively to make naming of similar entities for Ranges and Range Checks more consistent. Differential Revision: https://reviews.llvm.org/D39414 llvm-svn: 316979
* [X86] Make AVX512_512_SET0 XMM16-31 lower to 128-bit XOR when AVX512VL is ↵Craig Topper2017-10-3110-331/+320
| | | | | | | | | | enabled. Use 128-bit VLX instruction when VLX is enabled. Unfortunately, this weakens our ability to do domain fixing when AVX512DQ is not enabled, but it is consistent with our 256-bit behavior. Maybe we should add custom handling to domain fixing to allow EVEX integer XOR/AND/OR/ANDN to switch to VEX encoded fp instructions if the high registers aren't being used? llvm-svn: 316978
* [NFC] Get rid of variables used in assert onlyMax Kazantsev2017-10-311-6/+6
| | | | llvm-svn: 316977
* [IndVarSimplify] Simplify code using preheader assumptionPhilip Reames2017-10-312-44/+28
| | | | | | | | As noted in the nice block comment, the previous code didn't actually handle multi-entry loops correctly, it just assumed SCEV didn't analyze such loops. Given SCEV has comments to the contrary, that seems a bit suspect. More importantly, the pass actually requires loopsimplify form which ensures a loop-preheader is available. Remove the excessive generaility and shorten the code greatly. Note that we do successfully analyze many multi-entry loops, but we do so by converting them to single entry loops. See the added test case. llvm-svn: 316976
* Reapply "[GVN] Prevent LoadPRE from hoisting across instructions that don't ↵Max Kazantsev2017-10-316-0/+533
| | | | | | | | | | | | | | | | | | pass control flow to successors" This patch fixes the miscompile that happens when PRE hoists loads across guards and other instructions that don't always pass control flow to their successors. PRE is now prohibited to hoist across such instructions because there is no guarantee that the load standing after such instruction is still valid before such instruction. For example, a load from under a guard may be invalid before the guard in the following case: int array[LEN]; ... guard(0 <= index && index < LEN); use(array[index]); Differential Revision: https://reviews.llvm.org/D37460 llvm-svn: 316975
* [SimplifyIndVar] Extract out invariant expression handlingPhilip Reames2017-10-311-82/+107
| | | | | | | | Previously, the code returned early from the *function* when it couldn't find a free expansion, it should be returning from the *transform*. I don't have a test case, noticed this via inspection. As a follow up, I'm going to revisit the logic in the extract function. I think that essentially the whole helper routine can be replaced with SCEVExpander, but I wanted to do that in a series of separate commits. llvm-svn: 316974
* [X86] Clang-format some code. NFCCraig Topper2017-10-311-2/+8
| | | | llvm-svn: 316973
* [cmake] Make check_linker_flags operate via linker flagsShoaib Meenai2017-10-312-3/+5
| | | | | | | | | | | | | | | | | `check_linker_flags` currently sets the *compiler* flags (via `CMAKE_REQUIRED_FLAGS`), and thus implicitly relies on cmake's default behavior of passing the compiler flags to the linker. This breaks when cmake's build rules have been altered to not pollute the link line with compiler flags (which can be desirable for build cleanliness). Instead, set `CMAKE_EXE_LINKER_FLAGS` explicitly and use `CMP0056` to ensure the linker flags are passed along. Additionally, since we're inside a function, we can just alter the variable directly (as the alteration will be limited to the scope of the function) rather than saving and restoring the old value. Differential Revision: https://reviews.llvm.org/D39431 llvm-svn: 316972
* Undo accidental commitPhilip Reames2017-10-312-245/+82
| | | | | | These files shouldn't have been submitted in 316967 llvm-svn: 316968
* [CGP] Fix crash on i96 bit multiplyPhilip Reames2017-10-304-83/+256
| | | | | | | | Issue found by llvm-isel-fuzzer on OSS fuzz, https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3725 If anyone actually cares about > 64 bit arithmetic, there's a lot more to do in this area. There's a bunch of obviously wrong code in the same function. I don't have the time to fix all of them and am just using this to understand what the workflow for fixing fuzzer cases might look like. llvm-svn: 316967
* Fix unused variable warnings. NFCI.Simon Pilgrim2017-10-301-3/+0
| | | | llvm-svn: 316964
* [SelectionDAG] Tidyup computeKnownBits extension/truncation cases. NFCI.Simon Pilgrim2017-10-301-17/+4
| | | | | | We don't need to extend/truncate the Known structure before calling computeKnownBits - it will reset at the start of the function. llvm-svn: 316962
OpenPOWER on IntegriCloud