summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils
Commit message (Collapse)AuthorAgeFilesLines
...
* Move createMinMaxOp() out of RecurrenceDescriptor.Vikram TV2018-09-101-48/+47
| | | | | | | | | | Reviewers: dmgreen, llvm-commits Reviewed By: dmgreen Differential Revision: https://reviews.llvm.org/D51838 llvm-svn: 341773
* [MemorySSA] Update MemoryPhi wiring for block splitting to consider if ↵Alina Sbirlea2018-09-071-1/+2
| | | | | | | | | | | | | | | | | identical edges were merged. Summary: Block splitting is done with either identical edges being merged, or not. Only critical edges can be split without merging identical edges based on an option. Teach the memoryssa updater to take this into account: for the same edge between two blocks only move one entry from the Phi in Old to the new Phi in New. Reviewers: george.burgess.iv Subscribers: sanjoy, jlebar, Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D51563 llvm-svn: 341709
* [x86/SLH] Add a real Clang flag and LLVM IR attribute for SpeculativeChandler Carruth2018-09-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Load Hardening. Wires up the existing pass to work with a proper IR attribute rather than just a hidden/internal flag. The internal flag continues to work for now, but I'll likely remove it soon. Most of the churn here is adding the IR attribute. I talked about this Kristof Beyls and he seemed at least initially OK with this direction. The idea of using a full attribute here is that we *do* expect at least some forms of this for other architectures. There isn't anything *inherently* x86-specific about this technique, just that we only have an implementation for x86 at the moment. While we could potentially expose this as a Clang-level attribute as well, that seems like a good question to defer for the moment as it isn't 100% clear whether that or some other programmer interface (or both?) would be best. We'll defer the programmer interface side of this for now, but at least get to the point where the feature can be enabled without relying on implementation details. This also allows us to do something that was really hard before: we can enable *just* the indirect call retpolines when using SLH. For x86, we don't have any other way to mitigate indirect calls. Other architectures may take a different approach of course, and none of this is surfaced to user-level flags. Differential Revision: https://reviews.llvm.org/D51157 llvm-svn: 341363
* [SLC] Support expanding pow(x, n+0.5) to x * x * ... * sqrt(x)Florian Hahn2018-09-031-14/+52
| | | | | | | | | | Reviewers: evandro, efriedma, spatel Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D51435 llvm-svn: 341330
* [InstCombine] Expand the simplification of pow() into exp2()Evandro Menezes2018-08-301-5/+27
| | | | | | | | | | | | | Generalize the simplification of `pow(2.0, y)` to `pow(2.0 ** n, y)` for all scalar and vector types. This improvement helps some benchmarks in SPEC CPU2000 and CPU2006, such as 252.eon, 447.dealII, 453.povray. Otherwise, no significant regressions on x86-64 or A64. Differential revision: https://reviews.llvm.org/D49273 llvm-svn: 341095
* Revert "[SimplifyCFG] Common debug handling [NFC]"Martin Storsjo2018-08-301-0/+8
| | | | | | | | | This reverts commit r340997. This change turned out not to be NFC after all, but e.g. causes clang to crash when building the linux kernel for aarch64. llvm-svn: 341031
* [NFC] Move OrderedInstructions and InstructionPrecedenceTracking to AnalysisMax Kazantsev2018-08-304-153/+0
| | | | | | | | These classes don't make any changes to IR and have no reason to be in Transform/Utils. This patch moves them to Analysis folder. This will allow us reusing these classes in some analyzes, like MustExecute. llvm-svn: 341015
* [SimplifyCFG] Rename a variable for readibility of a future change [NFC]Philip Reames2018-08-301-8/+9
| | | | llvm-svn: 341004
* [SimplifyCFG] Fix a cost modeling oversight in branch commoningPhilip Reames2018-08-301-2/+8
| | | | | | | | The cost modeling was not accounting for the fact we were duplicating the instruction once per predecessor. With a default threshold of 1, this meant we were actually creating #pred copies. Adding to the fun, there is *absolutely no* test coverage for this. Simply bailing for more than one predecessor passes all checked in tests. llvm-svn: 341001
* [SimplifyCFG] Common debug handling [NFC]Philip Reames2018-08-291-8/+0
| | | | llvm-svn: 340997
* Revert r340947 "[InstCombine] Expand the simplification of pow() into exp2()"Reid Kleckner2018-08-291-25/+5
| | | | | | It broke the clang-cl self-host. llvm-svn: 340991
* [InstCombine] Expand the simplification of pow() with nested exp{,2}()Evandro Menezes2018-08-291-4/+21
| | | | | | | | | | | | Expand the simplification of `pow(exp{,2}(x), y)` to all FP types. This improvement helps some benchmarks in SPEC CPU2000 and CPU2006, such as 252.eon, 447.dealII, 453.povray. Otherwise, no significant regressions on x86-64 or A64. Differential revision: https://reviews.llvm.org/D51195 llvm-svn: 340948
* [InstCombine] Expand the simplification of pow() into exp2()Evandro Menezes2018-08-291-5/+25
| | | | | | | | | | | | | Generalize the simplification of `pow(2.0, y)` to `pow(2.0 ** n, y)` for all scalar and vector types. This improvement helps some benchmarks in SPEC CPU2000 and CPU2006, such as 252.eon, 447.dealII, 453.povray. Otherwise, no significant regressions on x86-64 or A64. Differential revision: https://reviews.llvm.org/D49273 llvm-svn: 340947
* Revert r340921 "[NFC] Unify guards detection"Hans Wennborg2018-08-291-6/+0
| | | | | | | | | | | | | | | | | | This broke the build, see e.g. http://lab.llvm.org:8011/builders/clang-cmake-armv8-lnt/builds/4626/ http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/18647/ http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/5856/ http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/22800/ > We have multiple places in code where we try to identify whether or not > some instruction is a guard. This patch factors out this logic into a separate > utility function which works uniformly in all places. > > Differential Revision: https://reviews.llvm.org/D51152 > Reviewed By: fedor.sergeev llvm-svn: 340923
* [NFC] Unify guards detectionMax Kazantsev2018-08-291-0/+6
| | | | | | | | | | | We have multiple places in code where we try to identify whether or not some instruction is a guard. This patch factors out this logic into a separate utility function which works uniformly in all places. Differential Revision: https://reviews.llvm.org/D51152 Reviewed By: fedor.sergeev llvm-svn: 340921
* [NFC] Factor out guard utility methods into a separate fileMax Kazantsev2018-08-292-0/+65
| | | | | | | | | | This patch creates file GuardUtils which will contain logic for work with guards that can be shared across different passes. Differential Revision: https://reviews.llvm.org/D51151 Reviewed By: fedor.sergeev llvm-svn: 340914
* [CloneFunction] Constant fold terminators before checking single predecessorMikael Holmen2018-08-281-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes PR31105. There is code trying to delete dead code that does so by e.g. checking if the single predecessor of a block is the block itself. That check fails on a block like this bb: br i1 undef, label %bb, label %bb since that has two (identical) predecessors. However, after the check for dead blocks there is a call to ConstantFoldTerminator on the basic block, and that call simplifies the block to bb: br label %bb Therefore we now do the call to ConstantFoldTerminator before the check if the block is dead, so it can realize that it really is. The original behavior lead to the block not being removed, but it was simplified as above, and then we did a call to Dest->replaceAllUsesWith(&*I); with old and new being equal, and an assertion triggered. Reviewers: chandlerc, fhahn Reviewed By: fhahn Subscribers: eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D51280 llvm-svn: 340820
* [PATCH] [InstCombine] Fix issue in the simplification of pow() with nested ↵Evandro Menezes2018-08-271-6/+22
| | | | | | | | | | | exp{,2}() Fix the issue of duplicating the call to `exp{,2}()` when it's nested in `pow()`, as exposed by rL340462. Differential revision: https://reviews.llvm.org/D51194 llvm-svn: 340784
* [NFC] Split logic of ImplicitControlFlowTracking to allow generalizationMax Kazantsev2018-08-273-94/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | We have a class `ImplicitControlFlowTracking` which allows us to keep track of instructions that can abnormally exit and answer queries like "whether or not there is side-exiting instruction above this instruction in its block". We may want to have the similar tracking for other types of "special" instructions, for example instructions that write memory. This patch separates ImplicitControlFlowTracking into two classes, isolating all general logic not related to implicit control flow into its parent class. We can later make another child of this class to keep track of instructions that write memory. The motivation for that is that we want to make these checks efficiently in the patch https://reviews.llvm.org/D50891. NOTE: The naming of the parent class is not super cool, but the other options we have are hardly better. Please feel free to rename it as NFC if you think you've found a more informative name for it. Differential Revision: https://reviews.llvm.org/D50954 Reviewed By: fedor.sergeev llvm-svn: 340728
* [IR] Replace `isa<TerminatorInst>` with `isTerminator()`.Chandler Carruth2018-08-266-11/+9
| | | | | | | | | | | | This is a bit awkward in a handful of places where we didn't even have an instruction and now we have to see if we can build one. But on the whole, this seems like a win and at worst a reasonable cost for removing `TerminatorInst`. All of this is part of the removal of `TerminatorInst` from the `Instruction` type hierarchy. llvm-svn: 340701
* [IR] Sink `isExceptional` predicate to `Instruction`, rename it toChandler Carruth2018-08-262-2/+2
| | | | | | | | | | | `isExceptionalTermiantor` and implement it for opcodes as well following the common pattern in `Instruction`. Part of removing `TerminatorInst` from the `Instruction` type hierarchy to make it easier to share logic and interfaces between instructions that are both terminators and not terminators. llvm-svn: 340699
* [IR] Begin removal of TerminatorInst by removing successor manipulation.Chandler Carruth2018-08-265-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The core get and set routines move to the `Instruction` class. These routines are only valid to call on instructions which are terminators. The iterator and *generic* range based access move to `CFG.h` where all the other generic successor and predecessor access lives. While moving the iterator here, simplify it using the iterator utilities LLVM provides and updates coding style as much as reasonable. The APIs remain pointer-heavy when they could better use references, and retain the odd behavior of `operator*` and `operator->` that is common in LLVM iterators. Adjusting this API, if desired, should be a follow-up step. Non-generic range iteration is added for the two instructions where there is an especially easy mechanism and where there was code attempting to use the range accessor from a specific subclass: `indirectbr` and `br`. In both cases, the successors are contiguous operands and can be easily iterated via the operand list. This is the first major patch in removing the `TerminatorInst` type from the IR's instruction type hierarchy. This change was discussed in an RFC here and was pretty clearly positive: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123407.html There will be a series of much more mechanical changes following this one to complete this move. Differential Revision: https://reviews.llvm.org/D47467 llvm-svn: 340698
* [Local] Make DoesKMove required for combineMetadata.Florian Hahn2018-08-242-4/+5
| | | | | | | | | | | | | | | This patch makes the DoesKMove argument non-optional, to force people to think about it. Most cases where it is false are either code hoisting or code sinking, where we pick one instruction from a set of equal instructions among different code paths. Reviewers: dberlin, nlopes, efriedma, davide Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D47475 llvm-svn: 340606
* Allow creating llvm::Function in non-zero address spacesAlexander Richardson2018-08-233-10/+10
| | | | | | | | | | | | | | | | | | | | Most users won't have to worry about this as all of the 'getOrInsertFunction' functions on Module will default to the program address space. An overload has been added to Function::Create to abstract away the details for most callers. This is based on https://reviews.llvm.org/D37054 but without the changes to make passing a Module to Function::Create() mandatory. I have also added some more tests and fixed the LLParser to accept call instructions for types in the program address space. Reviewed By: bjope Differential Revision: https://reviews.llvm.org/D47541 llvm-svn: 340519
* [LibCalls] Added returned attribute to libcallsDavid Bolvansky2018-08-231-3/+16
| | | | | | | | | | | | Reviewers: efriedma Reviewed By: efriedma Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51092 llvm-svn: 340512
* [NFC] Refactor simplification of pow()Evandro Menezes2018-08-221-1/+1
| | | | llvm-svn: 340476
* Update MemorySSA in BasicBlockUtils.Alina Sbirlea2018-08-215-23/+45
| | | | | | | | | | | Summary: Extend BasicBlocksUtils to update MemorySSA. Subscribers: sanjoy, arsenm, nhaehnle, jlebar, Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D45300 llvm-svn: 340365
* [CodeExtractor] Use 'normal destination' BB as insert point to store invoke ↵Florian Hahn2018-08-211-1/+9
| | | | | | | | | | | | | | | | | | | results. Currently CodeExtractor tries to use the next node after an invoke to place the store for the result of the invoke, if it is an out parameter of the region. This fails, as the invoke terminates the current BB. In that case, we can place the store in the 'normal destination' BB, as the result will only be available in that case. Reviewers: davidxl, davide, efriedma Reviewed By: davidxl Differential Revision: https://reviews.llvm.org/D51037 llvm-svn: 340331
* [BypassSlowDivision] Teach bypass slow division not to interfere with div by ↵Craig Topper2018-08-211-0/+9
| | | | | | | | | | | | | | constant where constants have been constant hoisted, but not moved from their basic block DAGCombiner doesn't pay attention to whether constants are opaque before doing the div by constant optimization. So BypassSlowDivision shouldn't introduce control flow that would make DAGCombiner unable to see an opaque constant. This can occur when a div and rem of the same constant are used in the same basic block. it will be hoisted, but not leave the block. Longer term we probably need to look into the X86 immediate cost model used by constant hoisting and maybe not mark div/rem immediates for hoisting at all. This fixes the case from PR38649. Differential Revision: https://reviews.llvm.org/D51000 llvm-svn: 340303
* [SimplifyCFG] Replace some uses of bitwise or with logical orJustin Bogner2018-08-201-25/+25
| | | | | | | It's clearer to use logical or for boolean values. Thanks to Steven Zhang for noticing! llvm-svn: 340153
* [InstCombine] Refactor the simplification of pow() (NFC)Evandro Menezes2018-08-171-32/+51
| | | | | | | Refactor all cases dealing with `exp{,2,10}()` into one function in preparation for D49273. Otherwise, NFC. llvm-svn: 340061
* [InstCombine] add reflection fold for tan(-x)Sanjay Patel2018-08-161-2/+5
| | | | | | | | | This is a follow-up suggested with rL339604. For tan(), we don't have a corresponding LLVM intrinsic -- unlike sin/cos -- so this is the only way/place that we can do this fold currently. llvm-svn: 339958
* Update MemorySSA in Local utils removing blocks.Alina Sbirlea2018-08-161-15/+24
| | | | | | | | | | Summary: Extend Local utils to update MemorySSA. Subscribers: sanjoy, jlebar, Prazek, george.burgess.iv, llvm-commits Differential Revision: https://reviews.llvm.org/D48790 llvm-svn: 339951
* [InstCombine] Expand the simplification of pow(x, 0.5) to sqrt(x)Evandro Menezes2018-08-161-31/+20
| | | | | | | | | Expand the number of cases when `pow(x, 0.5)` is simplified into `sqrt(x)` by considering the math semantics with more granularity. Differential revision: https://reviews.llvm.org/D50036 llvm-svn: 339887
* [SimplifyCFG] Remove pointer from SmallPtrSet before deletionChijun Sima2018-08-151-3/+3
| | | | | | | | | | | | | | | | | Summary: Previously, `eraseFromParent()` calls `delete` which invalidates the value of the pointer. Copying the value of the pointer later is undefined behavior in C++11 and implementation-defined (which may cause a segfault on implementations having strict pointer safety) in C++14. This patch removes the BasicBlock pointer from related SmallPtrSet before `delete` invalidates it in the SimplifyCFG pass. Reviewers: kuhar, dmgreen, davide, trentxintong Reviewed By: kuhar, dmgreen Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50717 llvm-svn: 339773
* [UnJ] Rename hasInvariantIterationCount to ↵David Green2018-08-152-3/+3
| | | | | | | | hasIterationCountInvariantInParent NFC This hopefully describes the API of the function more precisely. llvm-svn: 339762
* [NFC] Refactoring of LoopSafetyInfo, step 1Max Kazantsev2018-08-151-2/+2
| | | | | | | | | Turn structure into class, encapsulate methods, add clarifying comments. Differential Revision: https://reviews.llvm.org/D50693 Reviewed By: reames llvm-svn: 339752
* [NFC] Add sanitizing assertion to ICF trackerMax Kazantsev2018-08-151-1/+3
| | | | llvm-svn: 339751
* [SimplifyLibCalls] don't drop fast-math-flags on trig reflection folds ↵Sanjay Patel2018-08-131-1/+6
| | | | | | | | | | (retry r339608) Even though this code is below a function called optimizeFloatingPointLibCall(), we apparently can't guarantee that we're dealing with FPMathOperators, so bail out immediately if that's not true. llvm-svn: 339618
* revert r339608 - [SimplifyLibCalls] don't drop fast-math-flags on trig ↵Sanjay Patel2018-08-131-3/+1
| | | | | | | | | reflection folds Can't set the builder flags without knowing this is an FPMathOperator. I'll add a test for that and try again. llvm-svn: 339609
* [SimplifyLibCalls] don't drop fast-math-flags on trig reflection foldsSanjay Patel2018-08-131-1/+3
| | | | llvm-svn: 339608
* [SimplifyLibCalls] add reflection fold for -sin(-x) (PR38458)Sanjay Patel2018-08-131-15/+27
| | | | | | | | | | This is a very partial fix for the reported problem. I suspect we do not get this fold in most motivating cases because most of the time, the libcall would have been replaced by an intrinsic, and that optimization is handled elsewhere...but maybe it should be handled here? llvm-svn: 339604
* [SimplifyLibCalls] reduce code for optimizeCos; NFCISanjay Patel2018-08-131-9/+8
| | | | llvm-svn: 339588
* [SLC] Expand simplification of pow() for vector typesEvandro Menezes2018-08-131-40/+37
| | | | | | | | Also consider vector constants when simplifying `pow()`. Differential revision: https://reviews.llvm.org/D50035 llvm-svn: 339578
* [UnJ] Create a hasInvariantIterationCount function. NFCDavid Green2018-08-112-14/+23
| | | | | | | | | | Pulled out a separate function for some code that calculates if an inner loop iteration count is invariant to it's outer loop. Differential Revision: https://reviews.llvm.org/D50063 llvm-svn: 339500
* [InstCombine] Transform str(n)cmp to memcmpDavid Bolvansky2018-08-101-0/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Motivation examples: int strcmp_memcmp() { char buf[12]; return strcmp(buf, "key") == 0; } int strcmp_memcmp2() { char buf[12]; return strcmp(buf, "key") != 0; } int strncmp_memcmp() { char buf[12]; return strncmp(buf, "key", 3) == 0; } can be turned to memcmp. See test file for more cases. Reviewers: efriedma Reviewed By: efriedma Subscribers: spatel, llvm-commits Differential Revision: https://reviews.llvm.org/D50233 llvm-svn: 339410
* [Local] Add dbg location on unreachable inst in changeToUnreachableAnastasis Grammenos2018-08-071-1/+2
| | | | | | | | | | | | As show in https://bugs.llvm.org/show_bug.cgi?id=37960 it would be desirable to have debug location in the unreachable instruction. Also adds a unti test for this function. Differential Revision: https://reviews.llvm.org/D50340 llvm-svn: 339173
* [GVN,NewGVN] Keep nonnull if K does not move.Florian Hahn2018-08-071-5/+6
| | | | | | | | | | | | | | | | | | | In combineMetadata, we should be able to preserve K's nonnull metadata, if K does not move. This condition should hold for all replacements by NewGVN/GVN, but I added a bunch of assertions to verify that. Fixes PR35038. There probably are additional kinds of metadata that could be preserved using similar reasoning. This is follow-up work. Reviewers: dberlin, davide, efriedma, nlopes Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D47339 llvm-svn: 339149
* [GVN,NewGVN] Move patchReplacementInstruction to Utils/Local.hFlorian Hahn2018-08-071-0/+31
| | | | | | | | | | | | | This function is shared between both implementations. I am not sure if Utils/Local.h is the best place though. Reviewers: davide, dberlin, efriedma, xbolva00 Reviewed By: efriedma, xbolva00 Differential Revision: https://reviews.llvm.org/D47337 llvm-svn: 339138
* [NFC] Factor out implicit control flow logic from GVNMax Kazantsev2018-08-072-0/+92
| | | | | | | | | | | | | | Logic for tracking implicit control flow instructions was added to GVN to perform PRE optimizations correctly. It appears that GVN is not the only optimization that sometimes does PRE, so this logic is required in other places (such as Jump Threading). This is an NFC patch that encapsulates all ICF-related logic in a dedicated utility class separated from GVN. Differential Revision: https://reviews.llvm.org/D40293 llvm-svn: 339086
OpenPOWER on IntegriCloud