summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils
Commit message (Collapse)AuthorAgeFilesLines
* Revert r255115 until we figure out how to fix the bot failures.Silviu Baranga2015-12-092-45/+2
| | | | llvm-svn: 255117
* [LV][LAA] Add a layer over SCEV to apply run-time checked knowledge on SCEV ↵Silviu Baranga2015-12-092-2/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expressions Summary: This change creates a layer over ScalarEvolution for LAA and LV, and centralizes the usage of SCEV predicates. The SCEVPredicatedLayer takes the statically deduced knowledge by ScalarEvolution and applies the knowledge from the SCEV predicates. The end goal is that both LAA and LV should use this interface everywhere. This also solves a problem involving the result of SCEV expression rewritting when the predicate changes. Suppose we have the expression (sext {a,+,b}) and two predicates P1: {a,+,b} has nsw P2: b = 1. Applying P1 and then P2 gives us {a,+,1}, while applying P2 and the P1 gives us sext({a,+,1}) (the AddRec expression was changed by P2 so P1 no longer applies). The SCEVPredicatedLayer maintains the order of transformations by feeding back the results of previous transformations into new transformations, and therefore avoiding this issue. The SCEVPredicatedLayer maintains a cache to remember the results of previous SCEV rewritting results. This also has the benefit of reducing the overall number of expression rewrites. Reviewers: mzolotukhin, anemet Subscribers: jmolloy, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D14296 llvm-svn: 255115
* Return a std::unique_ptr from CloneModule. NFC.Rafael Espindola2015-12-081-13/+15
| | | | llvm-svn: 255078
* [OperandBundles] Fix a transform in simplifycfgSanjoy Das2015-12-081-2/+6
| | | | | | | | | | Reviewers: pcc, majnemer, reames Subscribers: reames, llvm-commits Differential Revision: http://reviews.llvm.org/D15345 llvm-svn: 255062
* [OperandBundles] Remove unncessary constructorSanjoy Das2015-12-081-1/+1
| | | | | | | | The StringRef constructor is unnecessary (since we're converting to std::string anyway), and having it requires an explicit call to StringRef's or std::string's constructor. llvm-svn: 255000
* Create llvm.global_ctors in the new format.Rafael Espindola2015-12-061-2/+2
| | | | llvm-svn: 254878
* [SimplifyLibCalls] Optimization for pow(x, n) where n is some constantWeiming Zhao2015-12-041-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In order to avoid calling pow function we generate repeated fmul when n is a positive or negative whole number. For each exponent we pre-compute Addition Chains in order to minimize the no. of fmuls. Refer: http://wwwhomes.uni-bielefeld.de/achim/addition_chain.html We pre-compute addition chains for exponents upto 32 (which results in a max of 7 fmuls). For eg: 4 = 2+2 5 = 2+3 6 = 3+3 and so on Hence, pow(x, 4.0) ==> y = fmul x, x x = fmul y, y ret x For negative exponents, we simply compute the reciprocal of the final result. Note: This transformation is only enabled under fast-math. Patch by Mandeep Singh Grang <mgrang@codeaurora.org> Reviewers: weimingz, majnemer, escha, davide, scanon, joerg Subscribers: probinson, escha, llvm-commits Differential Revision: http://reviews.llvm.org/D13994 llvm-svn: 254776
* Move EH-specific helper functions to a more appropriate placeDavid Majnemer2015-12-021-1/+1
| | | | | | No functionality change is intended. llvm-svn: 254562
* Bring r254336 back:Rafael Espindola2015-12-011-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The difference is that now we don't error on out-of-comdat access to internal global values. We copy them instead. This seems to match the expectation of COFF linkers (see pr25686). Original message: Start deciding earlier what to link. A traditional linker is roughly split in symbol resolution and "copying stuff". The two tasks are badly mixed in lib/Linker. This starts splitting them apart. With this patch there are no direct call to linkGlobalValueBody or linkGlobalValueProto. Everything is linked via WapValue. This also includes a few fixes: * A GV goes undefined if the comdat is dropped (comdat11.ll). * We error if an internal GV goes undefined (comdat13.ll). * We don't link an unused comdat. The first two match the behavior of an ELF linker. The second one is equivalent to running globaldce on the input. llvm-svn: 254418
* [safestack] Protect byval function arguments.Evgeniy Stepanov2015-12-011-5/+11
| | | | | | | Detect unsafe byval function arguments and move them to the unsafe stack. llvm-svn: 254353
* This reverts commit r254336 and r254344.Rafael Espindola2015-11-301-3/+3
| | | | | | They broke a bot and I am debugging why. llvm-svn: 254347
* Start deciding earlier what to link.Rafael Espindola2015-11-301-3/+3
| | | | | | | | | | | | | | | | | | | | | | A traditional linker is roughly split in symbol resolution and "copying stuff". The two tasks are badly mixed in lib/Linker. This starts splitting them apart. With this patch there are no direct call to linkGlobalValueBody or linkGlobalValueProto. Everything is linked via WapValue. This also includes a few fixes: * A GV goes undefined if the comdat is dropped (comdat11.ll). * We error if an internal GV goes undefined (comdat13.ll). * We don't link an unused comdat. The first two match the behavior of an ELF linker. The second one is equivalent to running globaldce on the input. llvm-svn: 254336
* [SimplifyLibCalls] Transform log(exp2(y)) to y*log(2) under fast-math.Davide Italiano2015-11-301-1/+9
| | | | llvm-svn: 254317
* [SimplifyLibCalls] Don't crash if the function doesn't have a name.Davide Italiano2015-11-291-3/+2
| | | | llvm-svn: 254265
* [SimplifyLibCalls] Cross out implemented transformations.Davide Italiano2015-11-291-2/+0
| | | | llvm-svn: 254264
* [SimplifyLibCalls] Tranform log(pow(x, y)) -> y*log(x).Davide Italiano2015-11-291-5/+50
| | | | | | | | | | | | | | | | | | This one is enabled only under -ffast-math. There are cases where the difference between the value computed and the correct value is huge even for ffast-math, e.g. as Steven pointed out: x = -1, y = -4 log(pow(-1), 4) = 0 4*log(-1) = NaN I checked what GCC does and apparently they do the same optimization (which result in the dramatic difference). Future work might try to make this (slightly) less worse. Differential Revision: http://reviews.llvm.org/D14400 llvm-svn: 254263
* [SimplifyLibCalls] Use any_of(). Suggested by David Blaikie!Davide Italiano2015-11-281-4/+3
| | | | llvm-svn: 254239
* [SimplifyLibCalls] Fix inverted condition that lead to an uninitialized ↵Benjamin Kramer2015-11-281-2/+2
| | | | | | | | memory read below. Found by msan! llvm-svn: 254238
* Simplify the linking of recursive data.Rafael Espindola2015-11-271-2/+10
| | | | | | | | Now the ValueMapper has two callbacks. The first one maps the declaration. The ValueMapper records the mapping and then materializes the body/initializer. llvm-svn: 254209
* [SimplifyLibCalls] Use range-based loop. NFC.Davide Italiano2015-11-271-4/+2
| | | | llvm-svn: 254193
* [SimplifyLibCalls] Don't depend on a called function having a name, it might ↵Benjamin Kramer2015-11-261-11/+8
| | | | | | | | be an indirect call. Fixes the crasher in PR25651 and related crashers using the same pattern. llvm-svn: 254145
* [OperandBundles] Extract duplicated code into a helper function, NFCSanjoy Das2015-11-251-5/+1
| | | | llvm-svn: 254047
* [Utils] Put includes in correct order. NFC.Weiming Zhao2015-11-248-10/+8
| | | | | | | | | | | | | | | | | | | Summary: Followed the guidelines in: http://llvm.org/docs/CodingStandards.html#include-style However, I noticed that uppercase named headers come before lowercase ones throughout the codebase. So kept them as is. Patch by Mandeep Singh Grang <mgrang@codeaurora.org> Reviewers: majnemer, davide, jmolloy, atrick Subscribers: sanjoy Differential Revision: http://reviews.llvm.org/D14939 llvm-svn: 254005
* [SimplifyLibCalls] Removed some TODOs which are already implemented. NFC.Weiming Zhao2015-11-211-4/+0
| | | | | | | | | | | | | | Summary: D14302 implements tan(atan(x)) -> x D14045 implements pow(exp(x), y) -> exp(x*y) Patch by Mandeep Singh Grang <mgrang@codeaurora.org> Reviewers: majnemer, davide Differential Revision: http://reviews.llvm.org/D14882 llvm-svn: 253768
* Fix the debug build breakage that getDiscriminator is called by mistake.Dehao Chen2015-11-191-1/+2
| | | | llvm-svn: 253597
* Revert r253253 and r253126: "Don't recompute LCSSA after loop-unrolling when ↵Michael Zolotukhin2015-11-191-12/+2
| | | | | | | | | | | | possible." The change exposed a bug in IndVarSimplify (PR25578), which led to a failure (PR25538). When the bug is fixed, this patch can be reapplied. The tests are kept in tree, as they're useful anyway, and will not break with this revert. llvm-svn: 253596
* Reimplement discriminator assignment algorithm.Dehao Chen2015-11-191-52/+37
| | | | | | | | | | | | Summary: The new algorithm is more efficient (O(n), n is number of basic blocks). And it is guaranteed to cover all cases of multiple BB mapped to same line. Reviewers: dblaikie, davidxl, dnovillo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14738 llvm-svn: 253594
* Revert "Change memcpy/memset/memmove to have dest and source alignments."Pete Cooper2015-11-192-12/+11
| | | | | | | | | | This reverts commit r253511. This likely broke the bots in http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/20202 http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/3787 llvm-svn: 253543
* [SimplifyLibCalls] New trick: pow(x, 0.5) -> sqrt(x) under -ffast-math.Davide Italiano2015-11-181-2/+9
| | | | | | Differential Revision: http://reviews.llvm.org/D14466 llvm-svn: 253521
* [BuildLibCalls] EmitStrNLen() is dead code. Garbage collect.Davide Italiano2015-11-181-26/+0
| | | | llvm-svn: 253514
* Change memcpy/memset/memmove to have dest and source alignments.Pete Cooper2015-11-182-11/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note, this was reviewed (and more details are in) http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html These intrinsics currently have an explicit alignment argument which is required to be a constant integer. It represents the alignment of the source and dest, and so must be the minimum of those. This change allows source and dest to each have their own alignments by using the alignment attribute on their arguments. The alignment argument itself is removed. There are a few places in the code for which the code needs to be checked by an expert as to whether using only src/dest alignment is safe. For those places, they currently take the minimum of src/dest alignments which matches the current behaviour. For example, code which used to read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 500, i32 8, i1 false) will now read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 8 %dest, i8* align 8 %src, i32 500, i1 false) For out of tree owners, I was able to strip alignment from calls using sed by replacing: (call.*llvm\.memset.*)i32\ [0-9]*\,\ i1 false\) with: $1i1 false) and similarly for memmove and memcpy. I then added back in alignment to test cases which needed it. A similar commit will be made to clang which actually has many differences in alignment as now IRBuilder can generate different source/dest alignments on calls. In IRBuilder itself, a new argument was added. Instead of calling: CreateMemCpy(Dst, Src, getInt64(Size), DstAlign, /* isVolatile */ false) you now call CreateMemCpy(Dst, Src, getInt64(Size), DstAlign, SrcAlign, /* isVolatile */ false) There is a temporary class (IntegerAlignment) which takes the source alignment and rejects implicit conversion from bool. This is to prevent isVolatile here from passing its default parameter to the source alignment. Note, changes in future can now be made to codegen. I didn't change anything here, but this change should enable better memcpy code sequences. Reviewed by Hal Finkel. llvm-svn: 253511
* Revert "Revert "Strip metadata when speculatively hoisting instructions ↵Igor Laevsky2015-11-181-0/+5
| | | | | | | | (r252604)" Failing clang test is now fixed by the r253458. llvm-svn: 253459
* [OperandBundles] Tighten OperandBundleDef's interface; NFCSanjoy Das2015-11-181-1/+1
| | | | llvm-svn: 253446
* Teach the inliner to track deoptimization stateSanjoy Das2015-11-182-6/+92
| | | | | | | | | | | | | | | | Summary: This change teaches LLVM's inliner to track and suitably adjust deoptimization state (tracked via deoptimization operand bundles) as it inlines through call sites. The operation is described in more detail in the LangRef changes. Reviewers: reames, majnemer, chandlerc, dexonsmith Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14552 llvm-svn: 253438
* [PR25538]: Fix a failure caused by r253126.Michael Zolotukhin2015-11-161-2/+2
| | | | | | | | | | | | | | | | In r253126 we stopped to recompute LCSSA after loop unrolling in all cases, except the unrolling is full and at least one of the loop exits is outside the parent loop. In other cases the transformation should not break LCSSA, but it turned out, that we also call SimplifyLoop on the parent loop, which might break LCSSA by itself. This fix just triggers LCSSA recomputation in this case as well. I'm committing it without a test case for now, but I'll try to invent one. It's a bit tricky because in an isolated test LoopSimplify would be scheduled before LoopUnroll, and thus will change the test and hide the problem. llvm-svn: 253253
* [SimplifyLibCalls] Generalize a comment. This doesn't apply only to sqrt.Davide Italiano2015-11-161-2/+2
| | | | llvm-svn: 253224
* Don't generate discriminators for calls to debug intrinsicsPavel Labath2015-11-161-17/+19
| | | | | | | | | | | | | | Summary: This fails a check in Verifier.cpp, which checks for location matches between the declared variable and the !dbg attachments. Reviewers: dnovillo, dblaikie, danielcdh Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14657 llvm-svn: 253194
* Also map the personality function in CloneFunctionIntoKeno Fischer2015-11-161-0/+7
| | | | | | | | | | | | | | | | Summary: The Old personality function gets copied over, but the Materializer didn't have a chance to inspect it (e.g. to fix up references to the correct module for the target function). Also add a verifier check that makes sure the personality routine is in the same module as the function whose personality it is. Reviewers: majnemer Subscribers: jevinskie, llvm-commits Differential Revision: http://reviews.llvm.org/D14474 llvm-svn: 253183
* Fix mapping of unmaterialized global values during metadata linkingTeresa Johnson2015-11-151-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The patch to move metadata linking after global value linking didn't correctly map unmaterialized global values to null as desired. They were in fact mapped to the source copy. It largely worked by accident since most module linker clients destroyed the source module which caused the source GVs to be replaced by null, but caused a failure with LTO linking on Windows: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312869.html The problem is that a null return value from materializeValueFor is handled by mapping the value to self. This is the desired behavior when materializeValueFor is passed a non-GlobalValue. The problem is how to distinguish that case from the case where we really do want to map to null. This patch addresses this by passing in a new flag to the value mapper indicating that unmapped global values should be mapped to null. Other Value types are handled as before. Note that the documented behavior of asserting on unmapped values when the flag RF_IgnoreMissingValues isn't set is currently disabled with FIXME notes due to bootstrap failures. I modified these disabled asserts so when they are eventually enabled again it won't assert for the unmapped values when the new RF_NullMapMissingGlobalValues flag is set. I also considered using a callback into the value materializer, but a flag seemed cleaner given that there are already existing flags. I also considered modifying materializeValueFor to return the input value when we want to map to source and then treat a null return to mean map to null. However, there are other value materializer subclasses that implement materializeValueFor, and they would all need to be audited and the return values possibly changed, which seemed error-prone. Reviewers: dexonsmith, joker.eph Subscribers: pcc, llvm-commits Differential Revision: http://reviews.llvm.org/D14682 llvm-svn: 253170
* Don't recompute LCSSA after loop-unrolling when possible.Michael Zolotukhin2015-11-141-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently we always recompute LCSSA for outer loops after unrolling an inner loop. That leads to compile time problem when we have big loop nests, and we can solve it by avoiding unnecessary work. For instance, if w eonly do partial unrolling, we don't break LCSSA, so we don't need to rebuild it. Also, if all exits from the inner loop are inside the enclosing loop, then complete unrolling won't break LCSSA either. I replaced unconditional LCSSA recomputation with conditional recomputation + unconditional assert and added several tests, which were failing when I experimented with it. Soon I plan to follow up with a similar patch for recalculation of dominators tree. Reviewers: hfinkel, dexonsmith, bogner, joker.eph, chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14526 llvm-svn: 253126
* [SimplifyLibCalls] Make a function shorter. NFC.Davide Italiano2015-11-121-10/+2
| | | | llvm-svn: 252970
* SamplePGO - Fix PR 25482 - Do not rely on llvm.dbg.cu for discriminatorsDiego Novillo2015-11-111-2/+2
| | | | | | | | | | | | | | | The discriminators pass relied on the presence of llvm.dbg.cu to decide whether to add discriminators, but this fails in the case where debug info is only enabled partially when -fprofile-sample-use is active. The reason llvm.dbg.cu is not present in these cases is to prevent codegen from emitting debug info (as it is only used for the sample profile pass). This changes the discriminators pass to also emit discriminators even when debug info is not being emitted. llvm-svn: 252763
* Revert "Strip metadata when speculatively hoisting instructions"Renato Golin2015-11-101-5/+0
| | | | | | | This reverts commit r252604, as it broke all ARM and AArch64 buildbots, as well as some x86, et al. llvm-svn: 252623
* Strip metadata when speculatively hoisting instructionsIgor Laevsky2015-11-101-0/+5
| | | | | | | | | | | | | | | | This is fix for PR24059. When we are hoisting instruction above some condition it may turn out that metadata on this instruction was control dependant on the condition. This metadata becomes invalid and we need to drop it. This patch should cover most obvious places of speculative execution (which I have found by greping isSafeToSpeculativelyExecute). I think there are more cases but at least this change covers the severe ones. Differential Revision: http://reviews.llvm.org/D14398 llvm-svn: 252604
* Add discriminators for call instructions that are from the same line and ↵Dehao Chen2015-11-091-0/+32
| | | | | | | | | | | | | | same basic block. Summary: Call instructions that are from the same line and same basic block needs to have separate discriminators to distinguish between different callsites. Reviewers: davidxl, dnovillo, dblaikie Subscribers: dblaikie, probinson, llvm-commits Differential Revision: http://reviews.llvm.org/D14464 llvm-svn: 252492
* Allow LLE/LD and the loop versioning infrastructure to use SCEV predicatesSilviu Baranga2015-11-091-22/+53
| | | | | | | | | | | | | | | | | | | Summary: LAA currently generates a set of SCEV predicates that must be checked by users. In the case of Loop Distribute/Loop Load Elimination, no such predicates could have been emitted, since we don't allow stride versioning. However, in the future there could be SCEV predicates that will need to be checked. This change adds support for SCEV predicate versioning in the Loop Distribute, Loop Load Eliminate and the loop versioning infrastructure. Reviewers: anemet Subscribers: mssimpso, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D14240 llvm-svn: 252467
* ADT: Remove last implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-11-071-4/+5
| | | | | | | | | | Some implicit ilist iterator conversions have crept back into Analysis, Transforms, Hexagon, and llvm-stress. This removes them. I'll commit a patch immediately after this to disallow them (in a separate patch so that it's easy to revert if necessary). llvm-svn: 252371
* [SimplifyLibCalls] Don't hardcode the function name.Davide Italiano2015-11-061-1/+2
| | | | llvm-svn: 252342
* [ValueTracking] Add parameters to isImpliedCondition; NFCSanjoy Das2015-11-061-1/+1
| | | | | | | | | | | | | | | | Summary: This change makes the `isImpliedCondition` interface similar to the rest of the functions in ValueTracking (in that it takes a DataLayout, AssumptionCache etc.). This is an NFC, intended to make a later diff less noisy. Depends on D14369 Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14391 llvm-svn: 252333
* DI: Reverse direction of subprogram -> function edge.Peter Collingbourne2015-11-051-3/+1
| | | | | | | | | | | | | | | | | | | | | | | Previously, subprograms contained a metadata reference to the function they described. Because most clients need to get or set a subprogram for a given function rather than the other way around, this created unneeded inefficiency. For example, many passes needed to call the function llvm::makeSubprogramMap() to build a mapping from functions to subprograms, and the IR linker needed to fix up function references in a way that caused quadratic complexity in the IR linking phase of LTO. This change reverses the direction of the edge by storing the subprogram as function-level metadata and removing DISubprogram's function field. Since this is an IR change, a bitcode upgrade has been provided. Fixes PR23367. An upgrade script for textual IR for out-of-tree clients is attached to the PR. Differential Revision: http://reviews.llvm.org/D14265 llvm-svn: 252219
OpenPOWER on IntegriCloud