summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[MemorySSA] Revert r293361 and r293363, as the tests fail under asan."Daniel Berlin2017-01-302-15/+34
| | | | | | | This reverts commit r293471, reapplying r293361 and r293363 with a fix for an out-of-bounds read. llvm-svn: 293474
* [MemorySSA] Revert r293361 and r293363, as the tests fail under asan.Sam McCall2017-01-302-27/+12
| | | | llvm-svn: 293471
* [MemorySSA] Correct an assertion surrounding with parentheses.Davide Italiano2017-01-301-3/+2
| | | | llvm-svn: 293453
* [InstCombine] Merge DebugLoc when speculatively hoisting store instructionTaewook Oh2017-01-281-8/+11
| | | | | | | | | | | | | | Summary: Along with https://reviews.llvm.org/D27804, debug locations need to be merged when hoisting store instructions as well. Not sure if just dropping debug locations would make more sense for this case, but as the branch instruction will have at least different discriminator with the hoisted store instruction, I think there will be no difference in practice. Reviewers: aprantl, andreadb, danielcdh Reviewed By: aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29062 llvm-svn: 293372
* MemorySSA: Allow movement to arbitrary placesDaniel Berlin2017-01-281-1/+7
| | | | | | | | | | | | Summary: Extend the MemorySSAUpdater API to allow movement to arbitrary places Reviewers: davide, george.burgess.iv Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29239 llvm-svn: 293363
* MemorySSA: Fix block numbering invalidation and replacement bugs discovered ↵Daniel Berlin2017-01-282-11/+20
| | | | | | by updater llvm-svn: 293361
* Cleanup dump() functions.Matthias Braun2017-01-282-4/+9
| | | | | | | | | | | | | | | | | | We had various variants of defining dump() functions in LLVM. Normalize them (this should just consistently implement the things discussed in http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html For reference: - Public headers should just declare the dump() method but not use LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) - The definition of a dump method should look like this: #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) LLVM_DUMP_METHOD void MyClass::dump() { // print stuff to dbgs()... } #endif llvm-svn: 293359
* MemorySSA: Move updater to its own fileDaniel Berlin2017-01-283-339/+373
| | | | llvm-svn: 293357
* Introduce a basic MemorySSA updater, that supports insertDef,Daniel Berlin2017-01-281-28/+368
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | insertUse, moveBefore and moveAfter operations. Summary: This creates a basic MemorySSA updater that handles arbitrary insertion of uses and defs into MemorySSA, as well as arbitrary movement around the CFG. It replaces the current splice API. It can be made to handle arbitrary control flow changes. Currently, it uses the same updater algorithm from D28934. The main difference is because MemorySSA is single variable, we have the complete def and use list, and don't need anyone to give it to us as part of the API. We also have to rename stores below us in some cases. If we go that direction in that patch, i will merge all the updater implementations (using an updater_traits or something to provide the get* functions we use, called read*/write* in that patch). Sadly, the current SSAUpdater algorithm is way too slow to use for what we are doing here. I have updated the tests we have to basically build memoryssa incrementally using the updater api, and make sure it still comes out the same. Reviewers: george.burgess.iv Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29047 llvm-svn: 293356
* NFC: Add debug tracing for more cases where loop unrolling fails.Anna Thomas2017-01-271-2/+8
| | | | llvm-svn: 293313
* [LangRef] Make @llvm.sqrt(x) return undef, rather than have UB, for negative x.Justin Lebar2017-01-271-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Some frontends emit a speculate-and-select idiom for sqrt, wherein they compute sqrt(x), check if x is negative, and select NaN if it is: %cmp = fcmp olt double %a, -0.000000e+00 %sqrt = call double @llvm.sqrt.f64(double %a) %ret = select i1 %cmp, double 0x7FF8000000000000, double %sqrt This is technically UB as the LangRef is written today if %a is ever less than -0. But emitting code that's compliant with the current definition of sqrt would require a branch, which would then prevent us from matching this idiom in SelectionDAG (which we do today -- ISD::FSQRT has defined behavior on negative inputs), because SelectionDAG looks at one BB at a time. Nothing in LLVM takes advantage of this undefined behavior, as far as we can tell, and the fact that llvm.sqrt has UB dates from its initial addition to the LangRef. Reviewers: arsenm, mehdi_amini, hfinkel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D28797 llvm-svn: 293242
* [LoopUnroll] Properly update loopinfo for runtime unrolling by 2Michael Kuperstein2017-01-262-9/+17
| | | | | | | | | | | Even when we don't create a remainder loop (that is, when we unroll by 2), we may duplicate nested loops into the remainder. This is complicated by the fact the remainder may itself be either inserted into an outer loop, or at the top level. In the latter case, we may need to create new top-level loops. Differential Revision: https://reviews.llvm.org/D29156 llvm-svn: 293124
* MemorySSA: Link all defs together into an intrusive defslist, to make ↵Daniel Berlin2017-01-251-36/+130
| | | | | | | | | | | | | | | | | | | | | | | updater easier Summary: This is the first in a series of patches to add a simple, generalized updater to MemorySSA. For MemorySSA, every def is may-def, instead of the normal must-def. (the best way to think of memoryssa is "everything is really one variable, with different versions of that variable at different points in the program). This means when updating, we end up having to do a bunch of work to touch defs below and above us. In order to support this quickly, i have ilist'd all the defs for each block. ilist supports tags, so this is quite easy. the only slightly messy part is that you can't have two iplists for the same type that differ only whether they have the ownership part enabled or not, because the traits are for the value type. The verifiers have been updated to test that the def order is correct. Reviewers: george.burgess.iv Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29046 llvm-svn: 293085
* [SimplifyCFG] Do not sink and merge inline-asm instructions.Akira Hatanaka2017-01-251-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Conservatively disable sinking and merging inline-asm instructions as doing so can potentially create arguments that cannot satisfy the inline-asm constraints. For example, SimplifyCFG used to do the following transformation: (before) if.then: %0 = call i32 asm "rorl $2, $0", "=&r,0,n"(i32 %r6, i32 8) br label %if.end if.else: %1 = call i32 asm "rorl $2, $0", "=&r,0,n"(i32 %r6, i32 6) br label %if.end (after) %.sink = select i1 %tobool, i32 6, i32 8 %0 = call i32 asm "rorl $2, $0", "=&r,0,n"(i32 %r6, i32 %.sink) This would result in a crash in the backend since only immediate integer operands are permitted for constraint "n". rdar://problem/30110806 Differential Revision: https://reviews.llvm.org/D29111 llvm-svn: 293025
* [PH] Replace uses of AssertingVH from members of analysis results withChandler Carruth2017-01-241-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a lazy-asserting PoisoningVH. AssertVH is fundamentally incompatible with cache-invalidation of analysis results. The invaliadtion happens after the AssertingVH has already fired. Instead, use a PoisoningVH that will assert if the dangling handle is ever used rather than merely be assigned or destroyed. This patch also removes all of the (numerous) doomed attempts to work around this fundamental incompatibility. It is a pretty significant simplification IMO. The most interesting change is in the Inliner where we still do some clearing because we don't want to rely on the coarse grained invalidation strategy of the containing pass manager. However, I prefer the approach that contains this logic to the cleanup phase of the Inliner, and I think we could enhance the CGSCC analysis management layer to make this even better in the future if desired. The rest is straight cleanup. I've also added a test for one of the harder cases to work around: when a *module analysis* contains many AssertingVHes pointing at functions. Differential Revision: https://reviews.llvm.org/D29006 llvm-svn: 292928
* Update domtree incrementally in loop peeling.Serge Pavlov2017-01-241-7/+30
| | | | | | | | | With this change dominator tree remains in sync after each step of loop peeling. Differential Revision: https://reviews.llvm.org/D29029 llvm-svn: 292895
* SimplifyLibCalls: Replace more unary libcalls with intrinsicsMatt Arsenault2017-01-231-28/+21
| | | | llvm-svn: 292855
* [LoopUnroll] First form LCSSA, then loop-simplifyMichael Kuperstein2017-01-231-18/+17
| | | | | | | | | | | | | Running non-LCSSA-preserving LoopSimplify followed by LCSSA on (roughly) the same loop is incorrect, since LoopSimplify may break LCSSA arbitrarily higher in the loop nest. Instead, run LCSSA first, and then run LCSSA-preserving LoopSimplify on the result. This fixes PR31718. Differential Revision: https://reviews.llvm.org/D29055 llvm-svn: 292854
* [Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)David L. Jones2017-01-234-446/+446
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The LibFunc::Func enum holds enumerators named for libc functions. Unfortunately, there are real situations, including libc implementations, where function names are actually macros (musl uses "#define fopen64 fopen", for example; any other transitively visible macro would have similar effects). Strictly speaking, a conforming C++ Standard Library should provide any such macros as functions instead (via <cstdio>). However, there are some "library" functions which are not part of the standard, and thus not subject to this rule (fopen64, for example). So, in order to be both portable and consistent, the enum should not use the bare function names. The old enum naming used a namespace LibFunc and an enum Func, with bare enumerators. This patch changes LibFunc to be an enum with enumerators prefixed with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override macros.) There are additional changes required in clang. Reviewers: rsmith Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits Differential Revision: https://reviews.llvm.org/D28476 llvm-svn: 292848
* Tweak ASCII art in Simplify CFG. NFCAmaury Sechet2017-01-231-1/+1
| | | | llvm-svn: 292792
* [PM] Sink an LCSSA preservation assert from the LoopSimplify pass intoChandler Carruth2017-01-212-14/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | the library routine shared with the new PM and other code. This assert checks that when LCSSA preservation is requested we start in LCSSA form. Without this early assert, given *very* complex test cases we can hit an assert or crash much later on when trying to preserve LCSSA. The new PM's loop simplify doesn't need to (and indeed can't) preserve LCSSA as the new PM doesn't deal in transforms in the dependency graph. But we asked the library to and shockingly, this didn't work very well! Stop doing that. Now the assert will tell us immediately with existing test cases. Before this, it took a pretty convoluted input to trigger this. However, sinking the assert also found a bug in LoopUnroll where we asked simplifyLoop to preserve LCSSA *right before we reform it*. That's kinda silly and unsurprising that it wasn't available. =D Stop doing that too. We also would assert that the unrolled loop was in LCSSA even if preserving LCSSA was never requested! I don't have a test case or anything here. I spotted it by inspection and it seems quite obvious. No logic change anyways, that's just avoiding a spurrious assert. llvm-svn: 292710
* Improve PGO support for the new inlinerEaswaran Raman2017-01-201-4/+68
| | | | | | | | | | | | | | | | | | | | | | | | This adds the following to the new PM based inliner in PGO mode: * Use block frequency analysis to derive callsite's profile count and use that to adjust thresholds of hot and cold callsites. * Incrementally update the BFI of the caller after a callee gets inlined into it. This incremental update is only within an invocation of the run method - BFI is not preserved across calls to run. Update the function entry count of the callee after inlining it into a caller. * I've tuned the thresholds for the hot and cold callsites using a hacked up version of the old inliner that explicitly computes BFI on a set of internal benchmarks and spec. Once the new PM based pipeline stabilizes (IIRC Chandler mentioned there are known issues) I'll benchmark this again and adjust the thresholds if required. Inliner PGO support. Differential revision: https://reviews.llvm.org/D28331 llvm-svn: 292666
* Preserve domtree and loop-simplify for runtime unrolling.Eli Friedman2017-01-183-21/+82
| | | | | | | | | | | | | | | | | Mostly straightforward changes; we just didn't do the computation before. One sort of interesting change in LoopUnroll.cpp: we weren't handling dominance for children of the loop latch correctly, but foldBlockIntoPredecessor hid the problem for complete unrolling. Currently punting on loop peeling; made some minor changes to isolate that problem to LoopUnrollPeel.cpp. Adds a flag -unroll-verify-domtree; it verifies the domtree immediately after we finish updating it. This is on by default for +Asserts builds. Differential Revision: https://reviews.llvm.org/D28073 llvm-svn: 292447
* Cloning: Copy comdats when cloning globals.Peter Collingbourne2017-01-181-0/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D28838 llvm-svn: 292430
* Fix up a comment. NFC.Michael Kuperstein2017-01-181-1/+0
| | | | llvm-svn: 292425
* [LV] Allow reductions that have several uses outside the loopMichael Kuperstein2017-01-181-5/+12
| | | | | | | | | | | We currently check whether a reduction has a single outside user. We don't really need to require that - we just need to make sure a single value is used externally. The number of external users of that value shouldn't actually matter. Differential Revision: https://reviews.llvm.org/D28830 llvm-svn: 292424
* [Target, Transforms] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2017-01-181-9/+18
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 292320
* SimplifyLibCalls: Remove checks for fabsMatt Arsenault2017-01-171-5/+7
| | | | | | | Use the intrinsic instead of emitting the libcall which will be replaced by the intrinsic. llvm-svn: 292176
* SimplifyLibCalls: Replace fabs libcalls with intrinsicsMatt Arsenault2017-01-171-6/+8
| | | | | | | | Add missing fabs(fpext) optimzation that worked with the call, and also fixes it creating a second fpext when there were multiple uses. llvm-svn: 292172
* [PM] Introduce an analysis set used to preserve all analyses overChandler Carruth2017-01-153-5/+8
| | | | | | | | | | | | | | | a function's CFG when that CFG is unchanged. This allows transformation passes to simply claim they preserve the CFG and analysis passes to check for the CFG being preserved to remove the fanout of all analyses being listed in all passes. I've gone through and removed or cleaned up as many of the comments reminding us to do this as I could. Differential Revision: https://reviews.llvm.org/D28627 llvm-svn: 292054
* [Transforms/Utils] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2017-01-141-6/+15
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 291983
* "Use" lambda captures which are otherwise only used in asserts. NFCDavid L. Jones2017-01-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The LLVM coding standards recommend "using" values that are only needed by asserts: http://llvm.org/docs/CodingStandards.html#assert-liberally Without this change, LLVM cannot bootstrap with -Werror as the second stage fails with this new warning: https://reviews.llvm.org/rL291905 See also the previous fixes: https://reviews.llvm.org/rL291916 https://reviews.llvm.org/rL291939 https://reviews.llvm.org/rL291940 https://reviews.llvm.org/rL291941 Reviewers: rsmith Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28695 llvm-svn: 291957
* [DebugInfo] Remove redundant check in SimplifyCFG; NFC.Robert Lougher2017-01-121-4/+3
| | | | llvm-svn: 291813
* [DebugInfo] DILocation variable declaration should be const; NFC.Robert Lougher2017-01-121-1/+1
| | | | llvm-svn: 291787
* [loop-unroll] Properly populate LoopInfo for loops cloned in LoopUnrollRuntime.Florian Hahn2017-01-101-3/+5
| | | | | | | | | | | | | | | | Summary: This fixes Transforms/LoopUnroll/runtime-loop3.ll which failed with EXTENSIVE_DEBUG, because the cloned basic blocks were not added to the correct sub-loops in LoopUnrollRuntime.cpp. Reviewers: dexonsmith, mzolotukhin Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28482 llvm-svn: 291619
* [loop-unroll] Factor out code to update LoopInfo (NFC).Florian Hahn2017-01-101-17/+33
| | | | | | | | Move the code to update LoopInfo for cloned basic blocks to addClonedBlockToLoopInfo, as suggested in https://reviews.llvm.org/D28482. llvm-svn: 291614
* [LV] Don't panic when encountering the IV of an outer loop.Michael Kuperstein2017-01-101-2/+7
| | | | | | | | | | | | | | | | | | Bail out instead of asserting when we encounter this situation, which can actually happen. The reason the test uses the new PM is that the "bad" phi, incidentally, gets cleaned up by LoopSimplify. But LICM can create this kind of phi and preserve loop simplify form, so the cleanup has no chance to run. This fixes PR31190. We may want to solve this in a less conservative manner, since this phi is actually uniform within the inner loop (or we may want LICM to output a cleaner promotion to begin with). Differential Revision: https://reviews.llvm.org/D28490 llvm-svn: 291589
* [SimplifyLibCalls] Propagate fast math flags while optimizing pow().Davide Italiano2017-01-101-1/+4
| | | | llvm-svn: 291577
* [SimplifyLibCalls] pow(x, -0.5) -> 1.0 / sqrt(x).Davide Italiano2017-01-091-0/+18
| | | | | | Differential Revision: https://reviews.llvm.org/D28479 llvm-svn: 291486
* SimplifyLibCalls: Remove incorrect optimization of fabsMatt Arsenault2017-01-071-10/+2
| | | | | | | | fabs(x * x) is not generally safe to assume x is positive if x is a NaN. This is also less general than it could be, so this will be replaced with a transformation on the intrinsic. llvm-svn: 291359
* [ThinLTO] Handle conflicting local names gracefullyTeresa Johnson2017-01-061-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: r285871 introduced an assert that was overly aggressive in the case of a same-named local in different same-named files (in different directories), where the source name and therefore the GUID ended up the same because the files were compiled in their own directory without any leading path. Change the handling in the promotion logic to get the summary for the version in that module. This also exposed an issue where we are not always importing the right copy, which is a performance not correctness issue (because the renaming is based on the module hash which must be different, see the bug report for details). I will fix that as a follow-on. Fixes PR31561. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28411 llvm-svn: 291304
* [ThinLTO] Add parenthesis as per build warningTeresa Johnson2017-01-051-3/+2
| | | | | | Fixes a warning about "||" and "&&" due to r291108. llvm-svn: 291119
* [ThinLTO] Subsume all importing checks into a single flagTeresa Johnson2017-01-051-6/+19
| | | | | | | | | | | | | | | | | | | Summary: This adds a new summary flag NotEligibleToImport that subsumes several existing flags (NoRename, HasInlineAsmMaybeReferencingInternal and IsNotViableToInline). It also subsumes the checking of references on the summary that was being done during the thin link by eligibleForImport() for each candidate. It is much more efficient to do that checking once during the per-module summary build and record it in the summary. Reviewers: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28169 llvm-svn: 291108
* Reapply "[SimplifyCFG] In sinkLastInstruction correctly set debugloc of ↵Robert Lougher2017-01-041-1/+9
| | | | | | | | | | | | | | | | | | | | common inst" This reapplies r289828 (reverted in r289833 as it broke the address sanitizer). The debugloc is now only set when the instruction is not a call, as this causes the verifier to assert (the inliner requires an inlinable callsite to have a debug loc if the caller and callee have debug info). Original commit message: Simplify CFG will try to sink the last instruction in a series of basic blocks, creating a "common" instruction in the successor block (sinkLastInstruction). When it does this, the debug location of the single instruction should be the merged debug locations of the commoned instructions. Original review: https://reviews.llvm.org/D27590 llvm-svn: 290973
* Make sure total loop body weight is preserved in loop peelingXin Tong2017-01-021-8/+17
| | | | | | | | | | | | | | | Summary: Regardless how the loop body weight is distributed, we should preserve total loop body weight. i.e. we should have same weight reaching the body of the loop or its duplicates in peeled and unpeeled case. Reviewers: mkuper, davidxl, anemet Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28179 llvm-svn: 290833
* fix typo; NFCSanjay Patel2017-01-021-1/+1
| | | | llvm-svn: 290827
* [Inliner] remove unnecessary null checks from AddAlignmentAssumptions(); NFCISanjay Patel2016-12-311-5/+3
| | | | | | | We bail out on the 1st line if the assumption cache is not set, so there's no need to check it after that. llvm-svn: 290787
* Add a comment for a todo in LoopUnroll post cleanupPhilip Reames2016-12-301-0/+5
| | | | llvm-svn: 290769
* [PM] Move the collection of call sites to a more appropriate placeChandler Carruth2016-12-271-9/+15
| | | | | | | | | | | | | | | | | | | | | inside of `InlineFunction`. Prior to this, call instructions are specifically being rewritten and replaced within the inlined region, invalidating some of the call sites. Several of these regions are using the same technique to walk the inlined region so this seems clearly safe up to this point. I've also added a short circuit to the scan for call sites based on what other code is doing. With this, the most common crash I've found in the new inliner code is fixed. I've turned it on for another test case that covers this scenario. I'll make my way through most of the other inliner test cases just to get some easy coverage next. llvm-svn: 290562
* [PM] Teach the always inliner in the new pass manager to supportChandler Carruth2016-12-261-0/+64
| | | | | | | | | | | | | | | | removing fully-dead comdats without removing dead entries in comdats with live members. This factors the core logic out of the current inliner's internals to a reusable utility and leverages that in both places. The factored out code should also be (minorly) more efficient in cases where we have very few dead functions or dead comdats to consider. I've added a test case to cover this behavior of the always inliner. This is the last significant bug in the new PM's always inliner I've found (so far). llvm-svn: 290557
OpenPOWER on IntegriCloud