summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* Reapply fix in r217988 (reverted in r217989) and remove the alternative fix ↵David Blaikie2014-09-171-1/+1
| | | | | | | | | | committed in r217987. This type isn't owned polymorphically (as demonstrated by making the dtor protected and everything still compiling) so just address the warning by protecting the base dtor and making the derived class final. llvm-svn: 217990
* Revert "Fix -Wnon-virtual-dtor warning introduced in r217982."David Blaikie2014-09-171-1/+1
| | | | | | | | An alternative fix was already committed. This reverts commit r217988. llvm-svn: 217989
* Fix -Wnon-virtual-dtor warning introduced in r217982.David Blaikie2014-09-171-1/+1
| | | | llvm-svn: 217988
* Fixing a build error.Chris Bieneman2014-09-171-1/+1
| | | | llvm-svn: 217983
* Refactoring SimplifyLibCalls to remove static initializers and generally ↵Chris Bieneman2014-09-172-1883/+1649
| | | | | | | | | | | | | | | | cleaning up the code. Summary: This eliminates ~200 lines of code mostly file scoped struct definitions that were unnecessary. Reviewers: chandlerc, resistor Reviewed By: resistor Subscribers: morisset, resistor, llvm-commits Differential Revision: http://reviews.llvm.org/D5364 llvm-svn: 217982
* [IndVarSimplify] Partially revert r217953 to see if this fixes the bots.Chad Rosier2014-09-171-1/+4
| | | | | | Specifically, disable widening of unsigned compare instructions. llvm-svn: 217962
* [IndVarSimplify] Widen loop compare instructions.Chad Rosier2014-09-171-3/+36
| | | | | | | This improves other optimizations such as LSR. A sext may be added to the compare's other operand, but this can often be hoisted outside of the loop. llvm-svn: 217953
* [InstCombine] Fix wrong folding of constant comparison involving ahsr and ↵Andrea Di Biagio2014-09-171-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | negative quantities (PR20945). Example: define i1 @foo(i32 %a) { %shr = ashr i32 -9, %a %cmp = icmp ne i32 %shr, -5 ret i1 %cmp } Before this fix, the instruction combiner wrongly thought that %shr could have never been equal to -5. Therefore, %cmp was always folded to 'true'. However, when %a is equal to 1, then %cmp evaluates to 'false'. Therefore, in this example, it is not valid to fold %cmp to 'true'. The problem was only affecting the case where the comparison was between negative quantities where one of the quantities was obtained from arithmetic shift of a negative constant. This patch fixes the problem with the wrong folding (fixes PR20945). With this patch, the 'icmp' from the example is now simplified to a comparison between %a and 1. This still allows us to get rid of the arithmetic shift (%shr). llvm-svn: 217950
* Remove dead code in SimplifyCFGJingyue Wu2014-09-151-43/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: UsedByBranch is always true according to how BonusInst is defined. Test Plan: Passes check-all, and also verified if (BonusInst && !UsedByBranch) { ... } is never entered during check-all. Reviewers: resistor, nadav, jingyue Reviewed By: jingyue Subscribers: llvm-commits, eliben, meheff Differential Revision: http://reviews.llvm.org/D5324 llvm-svn: 217824
* Add control of function merging to the PMBuilder.Nick Lewycky2014-09-131-0/+10
| | | | llvm-svn: 217731
* Simplify code. No functionality change.Benjamin Kramer2014-09-131-15/+3
| | | | llvm-svn: 217726
* [C API] Make the 'lower switch' pass available via the C API.Juergen Ributzka2014-09-111-0/+4
| | | | llvm-svn: 217630
* [AlignmentFromAssumptions] Don't crash just because the target is 32-bitHal Finkel2014-09-111-0/+4
| | | | | | | | | We used to crash processing any relevant @llvm.assume on a 32-bit target (because we'd ask SE to subtract expressions of differing types). I've copied our 'simple.ll' test, but with the data layout from arm-linux-gnueabihf to get some meaningful test coverage here. llvm-svn: 217574
* Add doInitialization/doFinalization to DataLayoutPass.Rafael Espindola2014-09-101-2/+1
| | | | | | | | | | | | | With this a DataLayoutPass can be reused for multiple modules. Once we have doInitialization/doFinalization, it doesn't seem necessary to pass a Module to the constructor. Overall this change seems in line with the idea of making DataLayout a required part of Module. With it the only way of having a DataLayout used is to add it to the Module. llvm-svn: 217548
* [AlignmentFromAssumptions] Don't divide by zero for unknown starting alignmentHal Finkel2014-09-101-2/+4
| | | | | | | | | | The routine that determines an alignment given some SCEV returns zero if the answer is unknown. In a case where we could determine the increment of an AddRec but not the starting alignment, we would compute the integer modulus by zero (which is illegal and traps). Prevent this by returning early if either the start or increment alignment is unknown (zero). llvm-svn: 217544
* [PassManager] Adding Hidden attribute to EnableMLSM optionGerolf Hoflehner2014-09-101-2/+2
| | | | llvm-svn: 217539
* [MergedLoadStoreMotion] Move pass enabling option to PassManagerBuilderGerolf Hoflehner2014-09-102-7/+8
| | | | llvm-svn: 217538
* Rename getMaximumUnrollFactor -> getMaxInterleaveFactor; also rename option ↵Sanjay Patel2014-09-101-39/+39
| | | | | | | | | | | names controlling this variable. "Unroll" is not the appropriate name for this variable. Clang already uses the term "interleave" in pragmas and metadata for this. Differential Revision: http://reviews.llvm.org/D5066 llvm-svn: 217528
* Removed misleading comment.Gerolf Hoflehner2014-09-101-1/+0
| | | | llvm-svn: 217527
* MergeFunctions: FunctionPtr has been renamed to FunctionNode.Stepan Dyatkovskiy2014-09-101-7/+7
| | | | | | | It's supposed to store additional pass information for current function here. That was the reason for name change. llvm-svn: 217483
* SampleProfile.cpp: Prune a stray \param added in r217437. [-Wdocumentation]NAKAMURA Takumi2014-09-091-1/+0
| | | | llvm-svn: 217465
* ScalarOpts/LLVMBuild.txt: Prune unused dependency to IPA.NAKAMURA Takumi2014-09-091-1/+1
| | | | llvm-svn: 217448
* ScalarOpts/LLVMBuild.txt: Reorder.NAKAMURA Takumi2014-09-091-1/+1
| | | | llvm-svn: 217447
* Re-factor sample profile reader into lib/ProfileData.Diego Novillo2014-09-092-394/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch moves the profile reading logic out of the Sample Profile transformation into a generic profile reader facility in lib/ProfileData. The intent is to use this new reader to implement a sample profile reader/writer that can be used to convert sample profiles from external sources into LLVM. This first patch introduces no functional changes. It moves the profile reading code from lib/Transforms/SampleProfile.cpp into lib/ProfileData/SampleProfReader.cpp. In subsequent patches I will: - Add a bitcode format for sample profiles to allow for more efficient encoding of the profile. - Add a writer for both text and bitcode format profiles. - Add a 'convert' command to llvm-profdata to be able to convert between the two (and serve as entry point for other sample profile formats). Reviewers: bogner, echristo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5250 llvm-svn: 217437
* Add a comment to getNewAlignmentDiff.Andrew Trick2014-09-071-2/+4
| | | | llvm-svn: 217350
* Check for all known bits on ret in InstCombineHal Finkel2014-09-072-0/+19
| | | | | | | | | | From a combination of @llvm.assume calls (and perhaps through other means, such as range metadata), it is possible that all bits of a return value might be known. Previously, InstCombine did not check for this (which is understandable given assumptions of constant propagation), but means that we'd miss simple cases where assumptions are involved. llvm-svn: 217346
* Make use of @llvm.assume from LazyValueInfoHal Finkel2014-09-072-32/+56
| | | | | | | | | | | | | | | | | | | | | | | This change teaches LazyValueInfo to use the @llvm.assume intrinsic. Like with the known-bits change (r217342), this requires feeding a "context" instruction pointer through many functions. Aside from a little refactoring to reuse the logic that turns predicates into constant ranges in LVI, the only new code is that which can 'merge' the range from an assumption into that otherwise computed. There is also a small addition to JumpThreading so that it can have LVI use assumptions in the same block as the comparison feeding a conditional branch. With this patch, we can now simplify this as expected: int foo(int a) { __builtin_assume(a > 5); if (a > 3) { bar(); return 1; } return 0; } llvm-svn: 217345
* Add an AlignmentFromAssumptions PassHal Finkel2014-09-074-0/+434
| | | | | | | | | | | | | | | | | | | | | This adds a ScalarEvolution-powered transformation that updates load, store and memory intrinsic pointer alignments based on invariant((a+q) & b == 0) expressions. Many of the simple cases we can get with ValueTracking, but we still need something like this for the more complicated cases (such as those with an offset) that require some algebra. Note that gcc's __builtin_assume_aligned's optional third argument provides exactly for this kind of 'misalignment' offset for which this kind of logic is necessary. The primary motivation is to fixup alignments for vector loads/stores after vectorization (and unrolling). This pass is added to the optimization pipeline just after the SLP vectorizer runs (which, admittedly, does not preserve SE, although I imagine it could). Regardless, I actually don't think that the preservation matters too much in this case: SE computes lazily, and this pass won't issue any SE queries unless there are any assume intrinsics, so there should be no real additional cost in the common case (SLP does preserve DT and LoopInfo). llvm-svn: 217344
* Add additional patterns for @llvm.assume in ValueTrackingHal Finkel2014-09-071-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This builds on r217342, which added the infrastructure to compute known bits using assumptions (@llvm.assume calls). That original commit added only a few patterns (to catch common cases related to determining pointer alignment); this change adds several other patterns for simple cases. r217342 contained that, for assume(v & b = a), bits in the mask that are known to be one, we can propagate known bits from the a to v. It also had a known-bits transfer for assume(a = b). This patch adds: assume(~(v & b) = a) : For those bits in the mask that are known to be one, we can propagate inverted known bits from the a to v. assume(v | b = a) : For those bits in b that are known to be zero, we can propagate known bits from the a to v. assume(~(v | b) = a): For those bits in b that are known to be zero, we can propagate inverted known bits from the a to v. assume(v ^ b = a) : For those bits in b that are known to be zero, we can propagate known bits from the a to v. For those bits in b that are known to be one, we can propagate inverted known bits from the a to v. assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can propagate inverted known bits from the a to v. For those bits in b that are known to be one, we can propagate known bits from the a to v. assume(v << c = a) : For those bits in a that are known, we can propagate them to known bits in v shifted to the right by c. assume(~(v << c) = a) : For those bits in a that are known, we can propagate them inverted to known bits in v shifted to the right by c. assume(v >> c = a) : For those bits in a that are known, we can propagate them to known bits in v shifted to the right by c. assume(~(v >> c) = a) : For those bits in a that are known, we can propagate them inverted to known bits in v shifted to the right by c. assume(v >=_s c) where c is non-negative: The sign bit of v is zero assume(v >_s c) where c is at least -1: The sign bit of v is zero assume(v <=_s c) where c is negative: The sign bit of v is one assume(v <_s c) where c is non-positive: The sign bit of v is one assume(v <=_u c): Transfer the known high zero bits assume(v <_u c): Transfer the known high zero bits (if c is know to be a power of 2, transfer one more) A small addition to InstCombine was necessary for some of the test cases. The problem is that when InstCombine was simplifying and, or, etc. it would fail to check the 'do I know all of the bits' condition before checking less specific conditions and would not fully constant-fold the result. I'm not sure how to trigger this aside from using assumptions, so I've just included the change here. llvm-svn: 217343
* Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)Hal Finkel2014-09-0730-250/+391
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change, which allows @llvm.assume to be used from within computeKnownBits (and other associated functions in ValueTracking), adds some (optional) parameters to computeKnownBits and friends. These functions now (optionally) take a "context" instruction pointer, an AssumptionTracker pointer, and also a DomTree pointer, and most of the changes are just to pass this new information when it is easily available from InstSimplify, InstCombine, etc. As explained below, the significant conceptual change is that known properties of a value might depend on the control-flow location of the use (because we care that the @llvm.assume dominates the use because assumptions have control-flow dependencies). This means that, when we ask if bits are known in a value, we might get different answers for different uses. The significant changes are all in ValueTracking. Two main changes: First, as with the rest of the code, new parameters need to be passed around. To make this easier, I grouped them into a structure, and I made internal static versions of the relevant functions that take this structure as a parameter. The new code does as you might expect, it looks for @llvm.assume calls that make use of the value we're trying to learn something about (often indirectly), attempts to pattern match that expression, and uses the result if successful. By making use of the AssumptionTracker, the process of finding @llvm.assume calls is not expensive. Part of the structure being passed around inside ValueTracking is a set of already-considered @llvm.assume calls. This is to prevent a query using, for example, the assume(a == b), to recurse on itself. The context and DT params are used to find applicable assumptions. An assumption needs to dominate the context instruction, or come after it deterministically. In this latter case we only handle the specific case where both the assumption and the context instruction are in the same block, and we need to exclude assumptions from being used to simplify their own ephemeral values (those which contribute only to the assumption) because otherwise the assumption would prove its feeding comparison trivial and would be removed. This commit adds the plumbing and the logic for a simple masked-bit propagation (just enough to write a regression test). Future commits add more patterns (and, correspondingly, more regression tests). llvm-svn: 217342
* Add functions for finding ephemeral valuesHal Finkel2014-09-073-8/+26
| | | | | | | | | | | | | | | | This adds a set of utility functions for collecting 'ephemeral' values. These are LLVM IR values that are used only by @llvm.assume intrinsics (directly or indirectly), and thus will be removed prior to code generation, implying that they should be considered free for certain purposes (like inlining). The inliner's cost analysis, and a few other passes, have been updated to account for ephemeral values using the provided functionality. This functionality is important for the usability of @llvm.assume, because it limits the "non-local" side-effects of adding llvm.assume on inlining, loop unrolling, etc. (these are hints, and do not generate code, so they should not directly contribute to estimates of execution cost). llvm-svn: 217335
* Add an Assumption-Tracking PassHal Finkel2014-09-0710-7/+59
| | | | | | | | | | | | | | | | | | | | | | | | This adds an immutable pass, AssumptionTracker, which keeps a cache of @llvm.assume call instructions within a module. It uses callback value handles to keep stale functions and intrinsics out of the map, and it relies on any code that creates new @llvm.assume calls to notify it of the new instructions. The benefit is that code needing to find @llvm.assume intrinsics can do so directly, without scanning the function, thus allowing the cost of @llvm.assume handling to be negligible when none are present. The current design is intended to be lightweight. We don't keep track of anything until we need a list of assumptions in some function. The first time this happens, we scan the function. After that, we add/remove @llvm.assume calls from the cache in response to registration calls and ValueHandle callbacks. There are no new direct test cases for this pass, but because it calls it validation function upon module finalization, we'll pick up detectable inconsistencies from the other tests that touch @llvm.assume calls. This pass will be used by follow-up commits that make use of @llvm.assume. llvm-svn: 217334
* InstCombine: Remove a special case patternDavid Majnemer2014-09-051-15/+18
| | | | | | | The special case did not work when run under -reassociate and can easily be expressed by a further generalization of an existing pattern. llvm-svn: 217227
* Enable noalias metadata by default and swap the order of the SLP and Loop ↵James Molloy2014-09-042-2/+2
| | | | | | | | vectorizers by default. After some time maturing, hopefully the flags themselves will be removed. llvm-svn: 217144
* [GVN] Format variable name.Tilmann Scheller2014-09-041-2/+2
| | | | | | Local variables need to start with an upper case letter. llvm-svn: 217133
* IndVarSimplify: Address review comments for r217102David Majnemer2014-09-041-4/+7
| | | | | | No functional change intended, just some cleanups and comments added. llvm-svn: 217115
* [asan] fix debug info produced for asan-coverage=2Kostya Serebryany2014-09-031-1/+3
| | | | llvm-svn: 217106
* IndVarSimplify: Don't let LFTR compare against a poison valueDavid Majnemer2014-09-031-6/+18
| | | | | | | | | | | | | | LinearFunctionTestReplace tries to use the *next* indvar to compare against when possible. However, it may be the case that the calculation for the next indvar has NUW/NSW flags and that it may only be safely used inside the loop. Using it in a comparison to calculate the exit condition could result in observing poison. This fixes PR20680. Differential Revision: http://reviews.llvm.org/D5174 llvm-svn: 217102
* [asan] add -asan-coverage=3: instrument all blocks and critical edges. Kostya Serebryany2014-09-031-2/+11
| | | | llvm-svn: 217098
* Make some helpers static or move into the llvm namespace.Benjamin Kramer2014-09-031-1/+1
| | | | llvm-svn: 217077
* Preserve IR flags (nsw, nuw, exact, fast-math) in SLP vectorizer (PR20802).Sanjay Patel2014-09-031-5/+30
| | | | | | | | | | | | | | | | | The SLP vectorizer should propagate IR-level optimization hints/flags (nsw, nuw, exact, fast-math) when converting scalar instructions into vectors. But this isn't a simple copy - we need to take the intersection (the logical 'and') of the sets of flags on the scalars. The solution is further complicated because we can have non-uniform (non-SIMD) vector ops after: http://reviews.llvm.org/D4015 http://llvm.org/viewvc/llvm-project?view=revision&revision=211339 The vast majority of changed files are existing tests that were not propagating IR flags, but I've also added a new test file for focused testing of IR flag possibilities. Differential Revision: http://reviews.llvm.org/D5172 llvm-svn: 217051
* Change name of copyFlags() to copyIRFlags(). Add convenience method for ↵Sanjay Patel2014-09-031-1/+1
| | | | | | | | | | logical 'and' of all flags. NFC. Adding 'IR' to the names in an attempt to be less ambiguous about the flags we're dealing with here. The 'and' method is needed by the SLPVectorizer (PR20802) and possibly other passes. llvm-svn: 217004
* Add pass-manager flags to use CFL AAHal Finkel2014-09-021-0/+5
| | | | | | | Add -use-cfl-aa (and -use-cfl-aa-in-codegen) to add CFL AA in the default pass managers (for easy testing). llvm-svn: 216978
* [asan] Assign a low branch weight to ASan's slow path, patch by Jonas ↵Kostya Serebryany2014-09-022-2/+5
| | | | | | Wagner. This speeds up asan (at least on SPEC) by 1%-5% or more. Also fix lint in dfsan. llvm-svn: 216972
* Generate extract for in-tree uses if the use is scalar operand in vectorized ↵Yi Jiang2014-09-021-18/+69
| | | | | | instruction. radar://18144665 llvm-svn: 216946
* unique_ptrify the result of SpecialCaseList::createDavid Blaikie2014-09-021-1/+1
| | | | llvm-svn: 216925
* LICM: Don't crash when an instruction is used by an unreachable BBDavid Majnemer2014-09-021-1/+6
| | | | | | | | | | | | | | | | | | | Summary: BBs might contain non-LCSSA'd values after the LCSSA pass is run if they are unreachable from the entry block. Normally, the users of the instruction would be PHIs but the unreachable BBs have normal users; rewrite their uses to be undef values. An alternative fix could involve fixing this at LCSSA but that would require this invariant to hold after subsequent transforms. If a BB created an unreachable block, they would be in violation of this. This fixes PR19798. Differential Revision: http://reviews.llvm.org/D5146 llvm-svn: 216911
* SROA: Don't insert instructions before a PHIDavid Majnemer2014-09-011-1/+4
| | | | | | | | | | | | | | | SROA may decide that it needs to insert a bitcast and would set it's insertion point before a PHI. This will create an invalid module right quick. Instead, choose the first insertion point in the basic block that holds our PHI. This fixes PR20822. Differential Revision: http://reviews.llvm.org/D5141 llvm-svn: 216891
* Revert "Revert two GEP-related InstCombine commits"David Majnemer2014-09-011-11/+42
| | | | | | | | | | | | | | This reverts commit r216698 which reverted r216523 and r216598. We would attempt to perform the transformation even if the match() failed because, as a side effect, it would set V. This would trick us into believing that we correctly found a place to correctly apply the transform. An additional test case was added to getelementptr.ll so that we might not regress in the future. llvm-svn: 216890
* Add a convenience method to copy wrapping, exact, and fast-math flags (NFC).Sanjay Patel2014-09-011-13/+3
| | | | | | | | | | | | | | The loop vectorizer preserves wrapping, exact, and fast-math properties of scalar instructions. This patch adds a convenience method to make that operation easier because we need to do this in the loop vectorizer, SLP vectorizer, and possibly other places. Although this is a 'no functional change' patch, I've added a testcase to verify that the exact flag is preserved by the loop vectorizer. The wrapping and fast-math flags are already checked in existing testcases. Differential Revision: http://reviews.llvm.org/D5138 llvm-svn: 216886
OpenPOWER on IntegriCloud