summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* [LCG] Fold otherwise unused variable into assert.Benjamin Kramer2017-08-051-3/+2
| | | | | | No functionality change intended. llvm-svn: 310173
* IPRA: Don't crash on null getCallPreservedMaskMatt Arsenault2017-08-051-3/+5
| | | | | | Kernels aren't callable, so they don't have a call preserved mask. llvm-svn: 310172
* [LCG] Completely remove the parent set and leaf tracking for RefSCCs.Chandler Carruth2017-08-051-176/+3
| | | | | | | | | | | | | | | | | | | | | | | After the previous series of patches, this is now trivial and deletes a pretty astonishing amount of complexity. This has been a long time coming, as the move toward a PO sequence of RefSCCs started eroding the underlying use cases for this half of the data structure. Among the biggest advantages here is that now there aren't two independent data structures that need to stay in sync. Some of my profiling has also indicated that updating the parent sets was among the most expensive parts of the lazy call graph. Eliminating it whole sale is likely to be a nice win in terms of compile time. Last but not least, I had discussed with some folks previously keeping it around for asserts and other correctness checking, but once the fundamentals of the parent and child checking were implemented without the parent sets their value in correctness checking was tiny and no where near worth the cost of the complexity required to keep everything up-to-date. llvm-svn: 310171
* [LCG] Re-implement the basic isParentOf, isAncestorOf, isChildOf, andChandler Carruth2017-08-051-10/+37
| | | | | | | | | | | | | | | | | isDescendantOf methods on RefSCCs in terms of the forward edges rather than the parent sets. This is technically slower, but probably not interestingly slower, and all of these routines were already so expensive that they're guarded behind both !NDEBUG and EXPENSIVE_CHECKS. This removes another non-critical usage of parent sets. I've also added some comments to try and help clarify to any potential users the costs of these routines. They're mostly useful for debugging, asserts, or other queries. llvm-svn: 310170
* [LCG] Add the concept of a "dead" node and use it to avoid a complexChandler Carruth2017-08-051-8/+1
| | | | | | | | | | | | | | | | | | | | | | walk over the parent set. When removing a single function from the call graph, we previously would walk the entire RefSCC's parent set and then walk every outgoing edge just to find the ones to remove. In addition to this being quite high complexity in theory, it is also the last fundamental use of the parent sets. With this change, when we remove a function we transform the node containing it to be recognizably "dead" and then teach the edge iterators to recognize edges to such nodes and skip them the same way they skip null edges. We can't move fully to using "dead" nodes -- when disconnecting two live nodes we need to null out the edge. But the complexity this adds to the edge sequence isn't too bad and the simplification of lazily handling this seems like a significant win. llvm-svn: 310169
* [AArch64] LSE Atomics reorg - part 1Joel Jones2017-08-054-102/+291
| | | | | | | | | | | | | | | Add memory synchronization semantics to LSE Atomics. The memory semantics feature will be added in a subsequent patch. In this patch, several corrections were added to the existing LSE Atomics implementation, based on the ARM Errata D11904 from 05/12/2017. Patch by: steleman Differential Revision: https://reviews.llvm.org/D35319 llvm-svn: 310167
* [LCG] Replace an implicit bool operator with a named function. (NFC)Chandler Carruth2017-08-051-2/+2
| | | | | | | | | The definition of 'false' here was already pretty vague and debatable, and I'm about to add another potential 'false' that would actually make much more sense in a bool operator. Especially given how rarely this is used, a nicely named method seems better. llvm-svn: 310165
* [LCG] When removing a dead function and clearing out the dataChandler Carruth2017-08-051-0/+2
| | | | | | | | structures, actually null out the graph pointers as well. We won't ever update these, and we certainly shouldn't be calling any methods on them, so it seems good to defensively nuke them. llvm-svn: 310164
* [LCG] Rather than walking the directed graph structure to update graphChandler Carruth2017-08-051-14/+4
| | | | | | | | | pointers in node objects, just walk the map from function to node. It doesn't have stable ordering, but works just as well and is much simpler. We don't need ordering when just updating internal pointers. llvm-svn: 310163
* [LCG] Remove the complex walk of the parent sets to update graphChandler Carruth2017-08-051-11/+2
| | | | | | | | | pointers. This is completely unnecessary as we have a trivial list of RefSCCs now that we can walk. llvm-svn: 310162
* [LCG] Remove the use of the parent sets to compute connectivity whenChandler Carruth2017-08-051-16/+14
| | | | | | | | | | merging RefSCCs. The logic to directly use the reference edges is simpler and not substantially slower (despite the comments to the contrary) because this is not actually an especially hot part of LCG in practice. llvm-svn: 310161
* [InstCombine] In foldSelectICmpAnd, if we need to to truncate from the 'and' ↵Craig Topper2017-08-051-8/+8
| | | | | | | | | | | | type to the 'select' type, do it after shifting right instead of just bailing. Previously we were always trying to emit the zext or truncate before any shift. This meant if the 'and' mask was larger than the size of the truncate we would skip the transformation. Now we shift the result of the and right first leaving the bit within the range of the truncate. This matches what we are doing in foldSelectICmpAndOr for the same problem. llvm-svn: 310159
* [X86] Teach fastisel to select calls to dllimport functionsReid Kleckner2017-08-052-9/+20
| | | | | | | | | | | | | | Summary: Direct calls to dllimport functions are very common Windows. We should add them to the -O0 fast path. Reviewers: rafael Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D36197 llvm-svn: 310152
* [libFuzzer] use the in-binary pc table (instead of PCs captured at run-time) ↵Kostya Serebryany2017-08-045-13/+25
| | | | | | to implement -exit_on_src_pos llvm-svn: 310151
* [libFuzzer] print PCs using the in-binary PC-table instead of relying on PCs ↵Kostya Serebryany2017-08-043-21/+40
| | | | | | captured at run-time llvm-svn: 310148
* Enable llvm-pdbutil to list enumerations using native PDB readerAdrian McCarthy2017-08-045-3/+211
| | | | | | | | | | | | | | | This extends the native reader to enable llvm-pdbutil to list the enums in a PDB and it includes a simple test. It does not yet list the values in the enumerations, which requires an actual implementation of NativeEnumSymbol::FindChildren. To exercise this code, use a command like: llvm-pdbutil pretty -native -enums foo.pdb Differential Revision: https://reviews.llvm.org/D35738 llvm-svn: 310144
* [InstCombine] narrow truncated add/sub/mul with constantSanjay Patel2017-08-041-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Name: narrow_sub %sub = sub i32 C1, %x %r = trunc i32 %sub to i8 => %xn = trunc i32 %x to i8 %narrowC = trunc i32 C1 to i8 %r = sub i8 %narrowC, %xn Name: narrow_add %add = add i32 %x, C1 %r = trunc i32 %add to i8 => %xn = trunc i32 %x to i8 %narrowC = trunc i32 C1 to i8 %r = add i8 %xn, %narrowC Name: narrow_mul %mul = mul i32 %x, C1 %r = trunc i32 %mul to i8 => %xn = trunc i32 %x to i8 %narrowC = trunc i32 C1 to i8 %r = mul i8 %xn, %narrowC http://rise4fun.com/Alive/QpS This doesn't solve PR34046 (failure to recognize rotate): https://bugs.llvm.org/show_bug.cgi?id=34046 ...but it reduces an extra complication in the description examples to a form that we can more easily match. llvm-svn: 310141
* [Support] Use FILE_SHARE_DELETE to fix RemoveFileOnSignal on WindowsReid Kleckner2017-08-041-3/+4
| | | | | | | | | | | | | | | | | Summary: Tools like clang that use RemoveFileOnSignal on their output files weren't actually able to clean up their outputs before this change. Now the call to llvm::sys::fs::remove succeeds and the temporary file is deleted. This is a stop-gap to fix clang before implementing the solution outlined in PR34070. Reviewers: davide Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D36337 llvm-svn: 310137
* BlockPlacement: add a flag to force cold block outlining w/o a profile.Kyle Butt2017-08-041-1/+6
| | | | | | NFC. llvm-svn: 310129
* [libFuzzer] re-enable fuzzer-printcovpcs.testKostya Serebryany2017-08-041-1/+1
| | | | llvm-svn: 310126
* Revert r310055, it caused PR34074.Nico Weber2017-08-041-100/+3
| | | | llvm-svn: 310123
* Revert r310058, it caused PR34073.Nico Weber2017-08-041-47/+2
| | | | llvm-svn: 310118
* [SCEV] Preserve NSW information for sext(subtract).Amara Emerson2017-08-041-3/+29
| | | | | | | | | | Pushes the sext onto the operands of a Sub if NSW is present. Also adds support for propagating the nowrap flags of the llvm.ssub.with.overflow intrinsic during analysis. Differential Revision: https://reviews.llvm.org/D35256 llvm-svn: 310117
* [GlobalISel] Remove the GISelAccessor API.Quentin Colombet2017-08-048-200/+75
| | | | | | | | | | Its sole purpose was to avoid spreading around ifdefs related to building global-isel. Since r309990, GlobalISel is not optional anymore, thus, we can get rid of this mechanism all together. NFC. llvm-svn: 310115
* [GlobalISel] Remove a stall comment in CMake.Quentin Colombet2017-08-041-3/+0
| | | | | | | | Thanks to Diana Picus <diana.picus@linaro.org> for noticing. NFC llvm-svn: 310114
* [libFuzzer] make a test more robustKostya Serebryany2017-08-041-1/+1
| | | | llvm-svn: 310113
* [libFuzzer] remove the now redundant 'LLVMFuzzer-' prefix from libFuzzer testsKostya Serebryany2017-08-0465-241/+241
| | | | llvm-svn: 310110
* [libFuzzer] split one test into severalKostya Serebryany2017-08-047-24/+24
| | | | llvm-svn: 310106
* [libFuzzer tests] Only enable libFuzzer tests ifGeorge Karpenkov2017-08-042-18/+16
| | | | | | -DLIBFUZZER_ENABLE_TESTS=ON is set. llvm-svn: 310100
* [SystemZ] Add support for 128-bit atomic load/store/cmpxchgUlrich Weigand2017-08-044-3/+165
| | | | | | | | | | | | This adds support for the main 128-bit atomic operations, using the SystemZ instructions LPQ, STPQ, and CDSG. Generating these instructions is a bit more complex than usual since the i128 type is not legal for the back-end. Therefore, we have to hook the LowerOperationWrapper and ReplaceNodeResults TargetLowering callbacks. llvm-svn: 310094
* [SystemZ] Eliminate unnecessary serialization operationsUlrich Weigand2017-08-041-9/+9
| | | | | | | | | | | We currently emit a serialization operation (bcr 14, 0) before every atomic load and after every atomic store. This is overly conservative. The SystemZ architecture actually does not require any serialization for atomic loads, and a serialization after an atomic store only if we need to enforce sequential consistency. This is what other compilers for the platform implement as well. llvm-svn: 310093
* Fix PR33514Evgeny Stupachenko2017-08-041-0/+6
| | | | | | | | | | | | | | Summary: The bug was uncovered after fix of PR23384 (part 3 of 3). The patch restricts pointer multiplication in SCEV computaion for ICmpZero. Reviewers: qcolombet Differential Revision: http://reviews.llvm.org/D36170 From: Evgeny Stupachenko <evstupac@gmail.com> <evgeny.v.stupachenko@intel.com> llvm-svn: 310092
* [libFuzzer] make trace-pc.test more reliableKostya Serebryany2017-08-041-1/+1
| | | | llvm-svn: 310091
* [AMDGPU] Implement llvm.amdgcn.set.inactive intrinsicConnor Abbott2017-08-043-1/+66
| | | | | | | | | | | | | | | | | | | Summary: This intrinsic lets us set inactive lanes to an identity value when implementing wavefront reductions. In combination with Whole Wavefront Mode, it lets inactive lanes be skipped over as required by GLSL/Vulkan. Lowering the intrinsic needs to happen post-RA so that RA knows that the destination isn't completely overwritten due to the EXEC shenanigans, so we need another pseudo-instruction to represent the un-lowered intrinsic. Reviewers: tstellar, arsenm Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye Differential Revision: https://reviews.llvm.org/D34719 llvm-svn: 310088
* [AMDGPU] Add support for Whole Wavefront ModeConnor Abbott2017-08-049-48/+383
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Whole Wavefront Wode (WWM) is similar to WQM, except that all of the lanes are always enabled, regardless of control flow. This is required for implementing wavefront reductions in non-uniform control flow, where we need to use the inactive lanes to propagate intermediate results, so they need to be enabled. We need to propagate WWM to uses (unless they're explicitly marked as exact) so that they also propagate intermediate results correctly. We do the analysis and exec mask munging during the WQM pass, since there are interactions with WQM for things that require both WQM and WWM. For simplicity, WWM is entirely block-local -- blocks are never WWM on entry or exit of a block, and WWM is not propagated to the block level. This means that computations involving WWM cannot involve control flow, but we only ever plan to use WWM for a few limited purposes (none of which involve control flow) anyways. Shaders can ask for WWM using the @llvm.amdgcn.wwm intrinsic. There isn't yet a way to turn WWM off -- that will be added in a future change. Finally, it turns out that turning on inactive lanes causes a number of problems with register allocation. While the best long-term solution seems like teaching LLVM's register allocator about predication, for now we need to add some hacks to prevent ourselves from getting into trouble due to constraints that aren't currently expressed in LLVM. For the gory details, see the comments at the top of SIFixWWMLiveness.cpp. Reviewers: arsenm, nhaehnle, tpr Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D35524 llvm-svn: 310087
* [AMDGPU] refactor WQM pass in preparation for WWM (NFCI)Connor Abbott2017-08-041-46/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Right now, the WQM pass conflates two different things when tracking the Needs of an instruction: 1. Needs can be StateWQM, which is propagated to other instructions, and means that this instruction (and everything it depends on) must be calculated in WQM. 2. Needs can be StateExact, which is not propagated to other instructions, and means that this instruction must not be calculated in WQM and WQM-ness must not be propagated past this instruction. This works now because there are only two different states, but in the future we want to be able to express things like "calculate this in WQM, but please disable WWM and don't propagate it" (to implement @llvm.amdgcn.set.inactive). In order to do this, we need to split the per-instruction Needs field in two: a new Needs field, which can only contain StateWQM (and in the future, StateWWM) and is propagated to sources, and a Disables field, which can also contain just StateWQM or nothing for now. We keep the per-block tracking the same for now, by translating Needs/Disables to the old representation with only StateWQM or StateExact. The other place that needs special handling is when we emit the state transitions. We could just translate back to the old representation there as well, which we almost do, but instead of 0 as a placeholder value for "any state," we explicitly or together all the states an instruction is allowed to be in. This lets us refactor the code in preparation for WWM, where we'll need to be able to handle things like "this instruction must be in Exact or WQM, but not WWM." Reviewers: arsenm, nhaehnle, tpr Subscribers: kzhuravl, wdng, yaxunl, dstuttard, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D35523 llvm-svn: 310086
* [AMDGPU] Add an llvm.amdgcn.wqm intrinsic for WQMConnor Abbott2017-08-045-1/+32
| | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, we assumed that certain types of instructions needed WQM in pixel shaders, particularly DS instructions and image sampling instructions. This was ok because with OpenGL, the assumption was correct. But we want to start using DPP instructions for derivatives as well as other things, so the assumption that we can infer whether to use WQM based on the instruction won't continue to hold. This intrinsic lets frontends like Mesa indicate what things need WQM based on their knowledge of the API, rather than second-guessing them in the backend. We need to keep around the old method of enabling WQM, but eventually we should remove it once Mesa catches up. For now, this will let us use DPP instructions for computing derivatives correctly. Reviewers: arsenm, tpr, nhaehnle Subscribers: kzhuravl, wdng, yaxunl, dstuttard, llvm-commits, t-tye Differential Revision: https://reviews.llvm.org/D35167 llvm-svn: 310085
* [MachineOperand] Add ChangeToTargetIndex method. NFCMarcello Maggioni2017-08-041-0/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D36301 llvm-svn: 310083
* [Support] Remove getPathFromOpenFD, it was unusedReid Kleckner2017-08-042-83/+0
| | | | | | | | | | | | | | Summary: It was added to support clang warnings about includes with case mismatches, but it ended up not being necessary. Reviewers: twoh, rafael Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D36328 llvm-svn: 310078
* Fixing buildbots: do not register check-fuzzer if clang or asan are notGeorge Karpenkov2017-08-041-12/+15
| | | | | | present. llvm-svn: 310077
* Drop Windows support from libFuzzer tests.George Karpenkov2017-08-049-55/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D36205 llvm-svn: 310076
* Port libFuzzer tests to LIT. Do not require two-stage build for check-fuzzer.George Karpenkov2017-08-0472-442/+341
| | | | | | | | | | | | | | | | | | | | | This revision ports all libFuzzer tests apart from the unittest to LIT. The advantages of doing so include: - Tests being self-contained - Much easier debugging of a single test - No need for using a two-stage compilation The unit-test is still compiled using CMake, but it does not need a freshly built compiler. NOTE: The previous two-stage bot configuration will NOT work, as in the second stage build LLVM_USE_SANITIZER is set, which disables ASAN from being built. Thus bots will be reconfigured in the next few commits. Differential Revision: https://reviews.llvm.org/D36295 llvm-svn: 310075
* [Inliner] Fix a typo in option description. NFC.Easwaran Raman2017-08-041-1/+1
| | | | llvm-svn: 310073
* [ARM] Use searchable-table for banked registersJaved Absar2017-08-041-44/+6
| | | | | | | | | | | | | This is a continuation of https://reviews.llvm.org/D36219 This patch uses reverse mapping (encoding->name) in ARMInstPrinter::printBankedRegOperand to get rid of hard-coded values (as pointed out by @olista01). Reviewed by: @fhahn, @rovka, @olista01 Differential Revision: https://reviews.llvm.org/D36260 llvm-svn: 310072
* [ArgPromotion] Preserve alignment of byval argument in new allocaReid Kleckner2017-08-041-1/+1
| | | | | | | | | | | The frontend may have requested a higher alignment for any reason, and downstream optimizations may already have taken advantage of it. We should keep the same alignment when moving the allocation from the parameter area to the local variable area. Fixes PR34038 llvm-svn: 310071
* [ConstantInt] Use ConstantInt::getValue instead of ↵Craig Topper2017-08-043-5/+5
| | | | | | | | Constant::getUniqueInteger in a few places where we obviously have a ConstantInt. NFC getUniqueInteger will ultimately call ConstantInt::getValue, but calling ConstantInt::getValue should be inlined. llvm-svn: 310069
* [AArch64] Fix an assertion for pre-index generation with unscaled loads/stores.Chad Rosier2017-08-041-2/+17
| | | | | | | Differential Revision: https://reviews.llvm.org/D36248 PR34035 llvm-svn: 310066
* Adjust the hotness threshold from 99.9% to 99%.Dehao Chen2017-08-041-1/+1
| | | | | | | | | | | | | | Summary: We originally set the hotness threshold as 99.9% to be consistent with gcc FDO. But because the inline heuristic is different between 2 compilers: llvm uses bottom-up algorithm while gcc uses priority based. The LLVM algorithm tends to inline too much early that prevents hot callsites from further inlined into its caller. Due to this restriction, we think it is reasonable to lower the hotness threshold to give priority to those that are really hot. Our experiments show that this change would improve performance on large applications. Note that the inline heuristic has great room for further tuning. Once the inline heuristics are refined, we could adjust this threshold to allow inlining for less hot callsites. Reviewers: davidxl, tejohnson, eraman Reviewed By: tejohnson Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D36317 llvm-svn: 310065
* [InstCombine] Fold single-use variable into assert.Benjamin Kramer2017-08-041-2/+2
| | | | | | Avoids unused variable warnings in Release builds. No functional change. llvm-svn: 310064
* [InstCombine] Remove the (not (sext)) case from foldBoolSextMaskToSelect and ↵Craig Topper2017-08-041-27/+8
| | | | | | | | | | | | | | | | | | | inline the remaining code to match visitOr Summary: The (not (sext)) case is really (xor (sext), -1) which should have been simplified to (sext (xor, 1)) before we got here. So we shouldn't need to handle it. With that taken care of we only need to two cases so don't need the swap anymore. This makes us in sync with the equivalent code in visitOr so inline this to match. Reviewers: spatel, eli.friedman, majnemer Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D36240 llvm-svn: 310063
OpenPOWER on IntegriCloud