summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Revert "DI: Fold constant arguments into a single MDString""Duncan P. N. Exon Smith2014-10-031-18/+2
| | | | | | | | | | | | | | | | | | | | | | This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
* Eliminate some deep std::vector copies. NFC.Benjamin Kramer2014-10-031-1/+1
| | | | llvm-svn: 218999
* Revert "DI: Fold constant arguments into a single MDString"Duncan P. N. Exon Smith2014-10-021-7/+10
| | | | | | This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
* DI: Fold constant arguments into a single MDStringDuncan P. N. Exon Smith2014-10-021-10/+7
| | | | | | | | | | | | | This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 218914
* Optimize square root squared (PR21126).Sanjay Patel2014-10-021-0/+5
| | | | | | | | | | | When unsafe-fp-math is enabled, we can turn sqrt(X) * sqrt(X) into X. This can happen in the real world when calculating x ** 3/2. This occurs in test-suite/SingleSource/Benchmarks/BenchmarkGame/n-body.c. Differential Revision: http://reviews.llvm.org/D5584 llvm-svn: 218906
* Use the local variable that other clauses around here are already using.Sanjay Patel2014-10-021-1/+1
| | | | llvm-svn: 218876
* [BUG][INDVAR] Fix for PR21014: wrong SCEV operands commuting for ↵Zinovy Nis2014-10-021-3/+12
| | | | | | | | | | | | non-commutative instructions My commit rL216160 introduced a bug PR21014: IndVars widens code 'for (i = ; i < ...; i++) arr[ CONST - i]' into 'for (i = ; i < ...; i++) arr[ i - CONST]' thus inverting index expression. This patch fixes it. Thanks to Jörg Sonnenberger for pointing. Differential Revision: http://reviews.llvm.org/D5576 llvm-svn: 218867
* DIBuilder: Encapsulate DIExpression's element typeDuncan P. N. Exon Smith2014-10-011-4/+3
| | | | | | | | `DIExpression`'s elements are 64-bit integers that are stored as `ConstantInt`. The accessors already encapsulate the storage. This commit updates the `DIBuilder` API to also encapsulate that. llvm-svn: 218797
* Move the complex address expression out of DIVariable and into an extraAdrian Prantl2014-10-013-25/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | argument of the llvm.dbg.declare/llvm.dbg.value intrinsics. Previously, DIVariable was a variable-length field that has an optional reference to a Metadata array consisting of a variable number of complex address expressions. In the case of OpPiece expressions this is wasting a lot of storage in IR, because when an aggregate type is, e.g., SROA'd into all of its n individual members, the IR will contain n copies of the DIVariable, all alike, only differing in the complex address reference at the end. By making the complex address into an extra argument of the dbg.value/dbg.declare intrinsics, all of the pieces can reference the same variable and the complex address expressions can be uniqued across the CU, too. Down the road, this will allow us to move other flags, such as "indirection" out of the DIVariable, too. The new intrinsics look like this: declare void @llvm.dbg.declare(metadata %storage, metadata %var, metadata %expr) declare void @llvm.dbg.value(metadata %storage, i64 %offset, metadata %var, metadata %expr) This patch adds a new LLVM-local tag to DIExpressions, so we can detect and pretty-print DIExpression metadata nodes. What this patch doesn't do: This patch does not touch the "Indirect" field in DIVariable; but moving that into the expression would be a natural next step. http://reviews.llvm.org/D4919 rdar://problem/17994491 Thanks to dblaikie and dexonsmith for reviewing this patch! Note: I accidentally committed a bogus older version of this patch previously. llvm-svn: 218787
* Revert r218778 while investigating buldbot breakage.Adrian Prantl2014-10-013-24/+25
| | | | | | "Move the complex address expression out of DIVariable and into an extra" llvm-svn: 218782
* Move the complex address expression out of DIVariable and into an extraAdrian Prantl2014-10-013-25/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | argument of the llvm.dbg.declare/llvm.dbg.value intrinsics. Previously, DIVariable was a variable-length field that has an optional reference to a Metadata array consisting of a variable number of complex address expressions. In the case of OpPiece expressions this is wasting a lot of storage in IR, because when an aggregate type is, e.g., SROA'd into all of its n individual members, the IR will contain n copies of the DIVariable, all alike, only differing in the complex address reference at the end. By making the complex address into an extra argument of the dbg.value/dbg.declare intrinsics, all of the pieces can reference the same variable and the complex address expressions can be uniqued across the CU, too. Down the road, this will allow us to move other flags, such as "indirection" out of the DIVariable, too. The new intrinsics look like this: declare void @llvm.dbg.declare(metadata %storage, metadata %var, metadata %expr) declare void @llvm.dbg.value(metadata %storage, i64 %offset, metadata %var, metadata %expr) This patch adds a new LLVM-local tag to DIExpressions, so we can detect and pretty-print DIExpression metadata nodes. What this patch doesn't do: This patch does not touch the "Indirect" field in DIVariable; but moving that into the expression would be a natural next step. http://reviews.llvm.org/D4919 rdar://problem/17994491 Thanks to dblaikie and dexonsmith for reviewing this patch! llvm-svn: 218778
* C API: Add LLVMCloneModule()Tom Stellard2014-10-011-0/+9
| | | | llvm-svn: 218775
* Revert r218721, r218735.Evgeniy Stepanov2014-10-013-155/+8
| | | | | | | | | | Failing bootstrap on Linux (arm, x86). http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/13139/steps/bootstrap%20clang/logs/stdio http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/470 http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/8518 llvm-svn: 218752
* [InstCombine] Fix for assert build failures caused by r218721Gerolf Hoflehner2014-10-011-1/+7
| | | | | | | | | The icmp-select-icmp optimization made the implicit assumption that the select-icmp instructions are in the same block and asserted on it. The fix explicitly checks for that condition and conservatively suppresses the optimization when it is violated. llvm-svn: 218735
* [InstCombine] Optimize icmp-select-icmpGerolf Hoflehner2014-10-013-8/+149
| | | | | | | | | | | | | | | | | | | | | | | | | | | In special cases select instructions can be eliminated by replacing them with a cheaper bitwise operation even when the select result is used outside its home block. The instances implemented are patterns like %x=icmp.eq %y=select %x,%r, null %z=icmp.eq|neq %y, null br %z,true, false ==> %x=icmp.ne %y=icmp.eq %r,null %z=or %x,%y br %z,true,false The optimization is integrated into the instruction combiner and performed only when all uses of the select result can be replaced by the select operand proper. For this dominator information is used and dominance is now a required analysis pass in the combiner. The optimization itself is iterative. The critical step is to replace the select result with the non-constant select operand. So the select becomes local and the combiner iteratively works out simpler code pattern and eventually eliminates the select. rdar://17853760 llvm-svn: 218721
* [SimplifyCFG] threshold for folding branches with common destinationJingyue Wu2014-09-302-73/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds a threshold that controls the number of bonus instructions allowed for folding branches with common destination. The original code allows at most one bonus instruction. With this patch, users can customize the threshold to allow multiple bonus instructions. The default threshold is still 1, so that the code behaves the same as before when users do not specify this threshold. The motivation of this change is that tuning this threshold significantly (up to 25%) improves the performance of some CUDA programs in our internal code base. In general, branch instructions are very expensive for GPU programs. Therefore, it is sometimes worth trading more arithmetic computation for a more straightened control flow. Here's a reduced example: __global__ void foo(int a, int b, int c, int d, int e, int n, const int *input, int *output) { int sum = 0; for (int i = 0; i < n; ++i) sum += (((i ^ a) > b) && (((i | c ) ^ d) > e)) ? 0 : input[i]; *output = sum; } The select statement in the loop body translates to two branch instructions "if ((i ^ a) > b)" and "if (((i | c) ^ d) > e)" which share a common destination. With the default threshold, SimplifyCFG is unable to fold them, because computing the condition of the second branch "(i | c) ^ d > e" requires two bonus instructions. With the threshold increased, SimplifyCFG can fold the two branches so that the loop body contains only one branch, making the code conceptually look like: sum += (((i ^ a) > b) & (((i | c ) ^ d) > e)) ? 0 : input[i]; Increasing the threshold significantly improves the performance of this particular example. In the configuration where both conditions are guaranteed to be true, increasing the threshold from 1 to 2 improves the performance by 18.24%. Even in the configuration where the first condition is false and the second condition is true, which favors shortcuts, increasing the threshold from 1 to 2 still improves the performance by 4.35%. We are still looking for a good threshold and maybe a better cost model than just counting the number of bonus instructions. However, according to the above numbers, we think it is at least worth adding a threshold to enable more experiments and tuning. Let me know what you think. Thanks! Test Plan: Added one test case to check the threshold is in effect Reviewers: nadav, eliben, meheff, resistor, hfinkel Reviewed By: hfinkel Subscribers: hfinkel, llvm-commits Differential Revision: http://reviews.llvm.org/D5529 llvm-svn: 218711
* Introduce support for custom wrappers for vararg functions.Lorenzo Martignoni2014-09-301-9/+18
| | | | | | Differential Revision: http://reviews.llvm.org/D5412 llvm-svn: 218671
* [IndVarSimplify] Widen loop unsigned compares.Chad Rosier2014-09-301-6/+2
| | | | | | | This patch extends r217953 to handle unsigned comparison. Phabricator revision: http://reviews.llvm.org/D5526 llvm-svn: 218659
* Use a loop to simplify the runtime unrolling prologue.Kevin Qin2014-09-291-118/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Runtime unrolling will create a prologue to execute the extra iterations which is can't divided by the unroll factor. It generates an if-then-else sequence to jump into a factor -1 times unrolled loop body, like extraiters = tripcount % loopfactor if (extraiters == 0) jump Loop: if (extraiters == loopfactor) jump L1 if (extraiters == loopfactor-1) jump L2 ... L1: LoopBody; L2: LoopBody; ... if tripcount < loopfactor jump End Loop: ... End: It means if the unroll factor is 4, the loop body will be 7 times unrolled, 3 are in loop prologue, and 4 are in the loop. This commit is to use a loop to execute the extra iterations in prologue, like extraiters = tripcount % loopfactor if (extraiters == 0) jump Loop: else jump Prol Prol: LoopBody; extraiters -= 1 // Omitted if unroll factor is 2. if (extraiters != 0) jump Prol: // Omitted if unroll factor is 2. if (tripcount < loopfactor) jump End Loop: ... End: Then when unroll factor is 4, the loop body will be copied by only 5 times, 1 in the prologue loop, 4 in the original loop. And if the unroll factor is 2, new loop won't be created, just as the original solution. llvm-svn: 218604
* [IndVar] Don't widen loop compare unless IV user is sign extended.Chad Rosier2014-09-261-2/+6
| | | | | | PR21030 llvm-svn: 218539
* [asan] don't instrument module CTORs that may be run before ↵Kostya Serebryany2014-09-241-4/+6
| | | | | | asan.module_ctor. This fixes asan running together -coverage llvm-svn: 218421
* Fix assertion in LICM doFinalization()David Peixotto2014-09-241-0/+13
| | | | | | | | | | | | | | | | The doFinalization method checks that the LoopToAliasSetMap is empty. LICM populates that map as it runs through the loop nest, deleting the entries for child loops as it goes. However, if a child loop is deleted by another pass (e.g. unrolling) then the loop will never be deleted from the map because LICM walks the loop nest to find entries it can delete. The fix is to delete the loop from the map and free the alias set when the loop is deleted from the loop nest. Differential Revision: http://reviews.llvm.org/D5305 llvm-svn: 218387
* Allow BB duplication threshold to be adjusted through JumpThreading's ctorMichael Liao2014-09-241-7/+10
| | | | | | | - BB duplication may not be desired on targets where there is no or small branch penalty and code duplication needs restrict control. llvm-svn: 218375
* GlobalOpt: Preserve comdats of unoptimized initializersReid Kleckner2014-09-231-45/+26
| | | | | | | | | | | | | Rather than slurping in and splatting out the whole ctor list, preserve the existing array entries without trying to understand them. Only remove the entries that we know we can optimize away. This way we don't need to wire through priority and comdats or anything else we might add. Fixes a linker issue where the .init_array or .ctors entry would point to discarded initialization code if the comdat group from the TU with the faulty global_ctors entry was dropped. llvm-svn: 218337
* Using a deque to manage the stack of nodes is faster here.Lenny Maiorani2014-09-201-2/+6
| | | | | | | | | | Vector is slow due to many reallocations as the size regularly changes in unpredictable ways. See the investigation provided on the mailing list for more information: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120116/135228.html llvm-svn: 218182
* Add a new pass FunctionTargetTransformInfo. This pass serves as aEric Christopher2014-09-181-3/+8
| | | | | | | | | | | shim between the TargetTransformInfo immutable pass and the Subtarget via the TargetMachine and Function. Migrate a single call from BasicTargetTransformInfo as an example and provide shims where TargetMachine begins taking a Function to determine the subtarget. No functional change. llvm-svn: 218004
* 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
OpenPOWER on IntegriCloud