summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* Wisely choose sext or zext when widening IV.Evgeny Stupachenko2016-09-281-37/+88
| | | | | | | | | | | | Summary: The patch fixes regression caused by two earlier patches D18777 and D18867. Reviewers: reames, sanjoy Differential Revision: http://reviews.llvm.org/D24280 From: Li Huang llvm-svn: 282650
* Refactor the ProfileSummaryInfo to use doInitialization and doFinalization ↵Dehao Chen2016-09-281-1/+1
| | | | | | | | | | | | | | to handle Module update. Summary: This refactors the change in r282616 Reviewers: davidxl, eraman, mehdi_amini Subscribers: mehdi_amini, davide, llvm-commits Differential Revision: https://reviews.llvm.org/D25041 llvm-svn: 282630
* [SystemZ] Implementation of getUnrollingPreferences().Jonas Paulsson2016-09-281-6/+3
| | | | | | | | | | | | | | This commit enables more unrolling for SystemZ by implementing the SystemZTargetTransformInfo::getUnrollingPreferences() method. It has been found that it is better to only unroll moderately, so the DefaultUnrollRuntimeCount has been moved into UnrollingPreferences in order to set this to a lower value for SystemZ (4). Reviewers: Evgeny Stupachenko, Ulrich Weigand. https://reviews.llvm.org/D24451 llvm-svn: 282570
* [Inliner] Port all opt remarks to new streaming APIAdam Nemet2016-09-271-34/+35
| | | | llvm-svn: 282559
* Shorten DiagnosticInfoOptimizationRemark* to OptimizationRemark*. NFCAdam Nemet2016-09-274-7/+5
| | | | | | | With the new streaming interface, these class names need to be typed a lot and it's way too looong. llvm-svn: 282544
* [Inliner] Fold the analysis remark into the missed remarkAdam Nemet2016-09-271-6/+4
| | | | | | | | | | | | | | | There is really no reason for these to be separate. The vectorizer started this pretty bad tradition that the text of the missed remarks is pretty meaningless, i.e. vectorization failed. There, you have to query analysis to get the full picture. I think we should just explain the reason for missing the optimization in the missed remark when possible. Analysis remarks should provide information that the pass gathers regardless whether the optimization is passing or not. llvm-svn: 282542
* [LoopSimplify] When simplifying phis in loop-simplify, do it only if it ↵Michael Zolotukhin2016-09-271-2/+4
| | | | | | preserves LCSSA form. llvm-svn: 282541
* Output optimization remarks in YAMLAdam Nemet2016-09-271-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (Re-committed after moving the template specialization under the yaml namespace. GCC was complaining about this.) This allows various presentation of this data using an external tool. This was first recommended here[1]. As an example, consider this module: 1 int foo(); 2 int bar(); 3 4 int baz() { 5 return foo() + bar(); 6 } The inliner generates these missed-optimization remarks today (the hotness information is pulled from PGO): remark: /tmp/s.c:5:10: foo will not be inlined into baz (hotness: 30) remark: /tmp/s.c:5:18: bar will not be inlined into baz (hotness: 30) Now with -pass-remarks-output=<yaml-file>, we generate this YAML file: --- !Missed Pass: inline Name: NotInlined DebugLoc: { File: /tmp/s.c, Line: 5, Column: 10 } Function: baz Hotness: 30 Args: - Callee: foo - String: will not be inlined into - Caller: baz ... --- !Missed Pass: inline Name: NotInlined DebugLoc: { File: /tmp/s.c, Line: 5, Column: 18 } Function: baz Hotness: 30 Args: - Callee: bar - String: will not be inlined into - Caller: baz ... This is a summary of the high-level decisions: * There is a new streaming interface to emit optimization remarks. E.g. for the inliner remark above: ORE.emit(DiagnosticInfoOptimizationRemarkMissed( DEBUG_TYPE, "NotInlined", &I) << NV("Callee", Callee) << " will not be inlined into " << NV("Caller", CS.getCaller()) << setIsVerbose()); NV stands for named value and allows the YAML client to process a remark using its name (NotInlined) and the named arguments (Callee and Caller) without parsing the text of the message. Subsequent patches will update ORE users to use the new streaming API. * I am using YAML I/O for writing the YAML file. YAML I/O requires you to specify reading and writing at once but reading is highly non-trivial for some of the more complex LLVM types. Since it's not clear that we (ever) want to use LLVM to parse this YAML file, the code supports and asserts that we're writing only. On the other hand, I did experiment that the class hierarchy starting at DiagnosticInfoOptimizationBase can be mapped back from YAML generated here (see D24479). * The YAML stream is stored in the LLVM context. * In the example, we can probably further specify the IR value used, i.e. print "Function" rather than "Value". * As before hotness is computed in the analysis pass instead of DiganosticInfo. This avoids the layering problem since BFI is in Analysis while DiagnosticInfo is in IR. [1] https://reviews.llvm.org/D19678#419445 Differential Revision: https://reviews.llvm.org/D24587 llvm-svn: 282539
* [DebugInfo] Add comments to phi dbg.value tracking code, NFCReid Kleckner2016-09-271-6/+8
| | | | | | | | | | | | LLVM developers might be surprised to learn that there are blocks without valid insertion points (catchswitch), so it seems worth calling that out explicitly. Also add a FIXME about what we should really be doing if we ever need to make optimized Windows EH code debuggable. While I'm here, make auto usage more consistent with LLVM standards and avoid an unecessary call to insertBefore. llvm-svn: 282521
* Revert "Output optimization remarks in YAML"Adam Nemet2016-09-271-8/+6
| | | | | | | | This reverts commit r282499. The GCC bots are failing llvm-svn: 282503
* Output optimization remarks in YAMLAdam Nemet2016-09-271-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows various presentation of this data using an external tool. This was first recommended here[1]. As an example, consider this module: 1 int foo(); 2 int bar(); 3 4 int baz() { 5 return foo() + bar(); 6 } The inliner generates these missed-optimization remarks today (the hotness information is pulled from PGO): remark: /tmp/s.c:5:10: foo will not be inlined into baz (hotness: 30) remark: /tmp/s.c:5:18: bar will not be inlined into baz (hotness: 30) Now with -pass-remarks-output=<yaml-file>, we generate this YAML file: --- !Missed Pass: inline Name: NotInlined DebugLoc: { File: /tmp/s.c, Line: 5, Column: 10 } Function: baz Hotness: 30 Args: - Callee: foo - String: will not be inlined into - Caller: baz ... --- !Missed Pass: inline Name: NotInlined DebugLoc: { File: /tmp/s.c, Line: 5, Column: 18 } Function: baz Hotness: 30 Args: - Callee: bar - String: will not be inlined into - Caller: baz ... This is a summary of the high-level decisions: * There is a new streaming interface to emit optimization remarks. E.g. for the inliner remark above: ORE.emit(DiagnosticInfoOptimizationRemarkMissed( DEBUG_TYPE, "NotInlined", &I) << NV("Callee", Callee) << " will not be inlined into " << NV("Caller", CS.getCaller()) << setIsVerbose()); NV stands for named value and allows the YAML client to process a remark using its name (NotInlined) and the named arguments (Callee and Caller) without parsing the text of the message. Subsequent patches will update ORE users to use the new streaming API. * I am using YAML I/O for writing the YAML file. YAML I/O requires you to specify reading and writing at once but reading is highly non-trivial for some of the more complex LLVM types. Since it's not clear that we (ever) want to use LLVM to parse this YAML file, the code supports and asserts that we're writing only. On the other hand, I did experiment that the class hierarchy starting at DiagnosticInfoOptimizationBase can be mapped back from YAML generated here (see D24479). * The YAML stream is stored in the LLVM context. * In the example, we can probably further specify the IR value used, i.e. print "Function" rather than "Value". * As before hotness is computed in the analysis pass instead of DiganosticInfo. This avoids the layering problem since BFI is in Analysis while DiagnosticInfo is in IR. [1] https://reviews.llvm.org/D19678#419445 Differential Revision: https://reviews.llvm.org/D24587 llvm-svn: 282499
* [sanitizer-coverage] fix a bug in trace-gepKostya Serebryany2016-09-271-1/+1
| | | | llvm-svn: 282467
* [sanitizer-coverage] don't emit the CTOR function if nothing has been ↵Kostya Serebryany2016-09-271-17/+21
| | | | | | instrumented llvm-svn: 282465
* Revert r277556. Add -lowertypetests-bitsets-level to control bitsets generationIvan Krasin2016-09-271-9/+2
| | | | | | | | | | | | | | | | Summary: We don't currently need this facility for CFI. Disabling individual hot methods proved to be a better strategy in Chrome. Also, the design of the feature is suboptimal, as pointed out by Peter Collingbourne. Reviewers: pcc Subscribers: kcc Differential Revision: https://reviews.llvm.org/D24948 llvm-svn: 282461
* LowerTypeTests: Remove unused variable.Peter Collingbourne2016-09-261-1/+0
| | | | llvm-svn: 282456
* LowerTypeTests: Create LowerTypeTestsModule class and move implementation ↵Peter Collingbourne2016-09-261-82/+74
| | | | | | there. Related simplifications. llvm-svn: 282455
* [thinlto] Basic thinlto fdo heuristicPiotr Padlewski2016-09-261-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch improves thinlto importer by importing 3x larger functions that are called from hot block. I compared performance with the trunk on spec, and there were about 2% on povray and 3.33% on milc. These results seems to be consistant and match the results Teresa got with her simple heuristic. Some benchmarks got slower but I think they are just noisy (mcf, xalancbmki, omnetpp)- running the benchmarks again with more iterations to confirm. Geomean of all benchmarks including the noisy ones were about +0.02%. I see much better improvement on google branch with Easwaran patch for pgo callsite inlining (the inliner actually inline those big functions) Over all I see +0.5% improvement, and I get +8.65% on povray. So I guess we will see much bigger change when Easwaran patch will land (it depends on new pass manager), but it is still worth putting this to trunk before it. Implementation details changes: - Removed CallsiteCount. - ProfileCount got replaced by Hotness - hot-import-multiplier is set to 3.0 for now, didn't have time to tune it up, but I see that we get most of the interesting functions with 3, so there is no much performance difference with higher, and binary size doesn't grow as much as with 10.0. Reviewers: eraman, mehdi_amini, tejohnson Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D24638 llvm-svn: 282437
* Remove pruning of phi nodes in MemorySSA - it makes updating harderDaniel Berlin2016-09-261-40/+5
| | | | | | | | | | Reviewers: george.burgess.iv Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24923 llvm-svn: 282419
* [LV] Scalarize instructions marked scalar after vectorizationMatthew Simpson2016-09-261-0/+9
| | | | | | | | | This patch ensures that we actually scalarize instructions marked scalar after vectorization. Previously, such instructions may have been vectorized instead. Differential Revision: https://reviews.llvm.org/D23889 llvm-svn: 282418
* [Coroutines] Part14: Handle coroutines with no suspend points.Gor Nishanov2016-09-262-0/+120
| | | | | | | | | | | | | | | Summary: If coroutine has no suspend points, remove heap allocation and turn a coroutine into a normal function. Also, if a pattern is detected that coroutine resumes or destroys itself prior to coro.suspend call, turn the suspend point into a simple jump to resume or cleanup label. This pattern occurs when coroutines are used to propagate errors in functions that return expected<T>. Reviewers: majnemer Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D24408 llvm-svn: 282414
* [InstCombine] Fixed bug introduced in r282237Alexey Bataev2016-09-261-6/+8
| | | | | | | | The index of the new insertelement instruction was evaluated in the wrong way, it was considered as the index of the inserted value instead of index of the position, where the value should be inserted. llvm-svn: 282401
* [InstCombine] Teach the udiv folding logic how to handle constant expressions.Andrea Di Biagio2016-09-261-11/+14
| | | | | | | | | | | | | | | | | | | This patch fixes PR30366. Function foldUDivShl() worked under the assumption that one of the values in input to the function was always an instance of llvm::Instruction. However, function visitUDivOperand() (the only user of foldUDivShl) was clearly violating that precondition; internally, visitUDivOperand() uses pattern matches to check the operands of a udiv. Pattern matchers for binary operators know how to handle both Instruction and ConstantExpr values. This patch fixes the problem in foldUDivShl(). Now we use pattern matchers instead of explicit casts to Instruction. The reduced test case from PR30366 has been added to test file InstCombine/udiv-simplify.ll. Differential Revision: https://reviews.llvm.org/D24565 llvm-svn: 282398
* ObjCARC: Don't look at users of ConstantDataDuncan P. N. Exon Smith2016-09-241-0/+11
| | | | | | | | | | | | | Stop looking at users of UndefValue and ConstantPointerNull in the objective C ARC optimizers. The other users aren't actually interesting, since they're not pointing at a particular object. I imagine these calls could be optimized through -instcombine... maybe they already are? These early returns will be required at some point in the future, with a WIP patch that asserts when someone accesses a use-list on ConstantData. llvm-svn: 282338
* Scalar: Ignore ConstantData in processAssumptionDuncan P. N. Exon Smith2016-09-241-0/+5
| | | | | | | | | | | | Assumptions on UndefValue and ConstantPointerNull aren't relevant to other users. Ignore them entirely to avoid wasting cycles walking through their (possibly extremely extensive (cross-module)) use-lists. It wasn't clear how to add a specific test for this, and it'll be covered anyway by an eventual patch that asserts when trying to access the use-list of an instance of ConstantData. llvm-svn: 282334
* GlobalStatus: Don't walk use-lists of ConstantDataDuncan P. N. Exon Smith2016-09-241-1/+1
| | | | | | | | | | | | Return early from llvm::isSafeToDestroyConstant() whenever the value `isa<ConstantData>()`. These constants are shared across the LLVMContext. We never really want to delete them here, and walking their use-lists can be very expensive. (This is motivated by an eventual goal of removing use-lists entirely from ConstantData.) llvm-svn: 282320
* [InstCombine] Fix for PR29124: reduce insertelements to shufflevectorAlexey Bataev2016-09-232-50/+138
| | | | | | | | | | | | | | | | | | | | | | | | | If inserting more than one constant into a vector: define <4 x float> @foo(<4 x float> %x) { %ins1 = insertelement <4 x float> %x, float 1.0, i32 1 %ins2 = insertelement <4 x float> %ins1, float 2.0, i32 2 ret <4 x float> %ins2 } InstCombine could reduce that to a shufflevector: define <4 x float> @goo(<4 x float> %x) { %shuf = shufflevector <4 x float> %x, <4 x float> <float undef, float 1.0, float 2.0, float undef>, <4 x i32><i32 0, i32 5, i32 6, i32 3> ret <4 x float> %shuf } Also, InstCombine tries to convert shuffle instruction to single insertelement, if one of the vectors is a constant vector and only a single element from this constant should be used in shuffle, i.e. shufflevector <4 x float> %v, <4 x float> <float undef, float 1.0, float undef, float undef>, <4 x i32> <i32 0, i32 5, i32 undef, i32 undef> -> insertelement <4 x float> %v, float 1.0, 1 Differential Revision: https://reviews.llvm.org/D24182 llvm-svn: 282237
* [InstCombine] fold X urem C -> X < C ? X : X - C when C is big (PR28672)Sanjay Patel2016-09-221-0/+8
| | | | | | | | | | | | We already have the udiv variant of this transform, so I think this is ok for InstCombine too even though there is an increase in IR instructions. As the tests and TODO comments show, the transform can lead to follow-on combines. This should fix: https://llvm.org/bugs/show_bug.cgi?id=28672 Differential Revision: https://reviews.llvm.org/D24527 llvm-svn: 282209
* Revert r282168 "GVN-hoist: fix store past load dependence analysis (PR30216)"Hans Wennborg2016-09-221-35/+28
| | | | | | | | and also the dependent r282175 "GVN-hoist: do not dereference null pointers" It's causing compiler crashes building Harfbuzz (PR30499). llvm-svn: 282199
* GVN-hoist: do not dereference null pointersSebastian Pop2016-09-221-0/+3
| | | | | | | there may be basic blocks without memory accesses, in which case the list of accesses is a null pointer. llvm-svn: 282175
* GVN-hoist: fix store past load dependence analysis (PR30216)Sebastian Pop2016-09-221-29/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | To hoist stores past loads, we used to search for potential conflicting loads on the hoisting path by following a MemorySSA def-def link from the store to be hoisted to the previous defining memory access, and from there we followed the def-use chains to all the uses that occur on the hoisting path. The problem is that the def-def link may point to a store that does not alias with the store to be hoisted, and so the loads that are walked may not alias with the store to be hoisted, and even as in the testcase of PR30216, the loads that may alias with the store to be hoisted are not visited. The current patch visits all loads on the path from the store to be hoisted to the hoisting position and uses the alias analysis to ask whether the store may alias the load. I was not able to use the MemorySSA functionality to ask for whether load and store are clobbered: I'm not sure which function to call, so I used a call to AA->isNoAlias(). Store past store is still working as before using a MemorySSA query: I added an extra test to pr30216.ll to make sure store past store does not regress. Differential Revision: https://reviews.llvm.org/D24517 llvm-svn: 282168
* GVN-hoist: fix typoSebastian Pop2016-09-221-1/+1
| | | | llvm-svn: 282165
* [compiler-rt] fix typo in option description [NFC]Etienne Bergeron2016-09-221-1/+1
| | | | llvm-svn: 282163
* GVN-hoist: only hoist relevant scalar instructionsSebastian Pop2016-09-221-0/+4
| | | | | | | | | | | | | | | | | | | Without this patch, GVN-hoist would think that a branch instruction is a scalar instruction and would try to value number it. The patch filters out all such kind of irrelevant instructions. A bit frustrating is that there is no easy way to discard all those very infrequent instructions, a bit like isa<TerminatorInst> that stands for a large family of instructions. I'm thinking that checking for those very infrequent other instructions would cost us more in compilation time than just letting those instructions getting numbered, so I'm still thinking that a simpler check: if (isa<TerminatorInst>(I)) return false; is better than listing all the other less frequent instructions. Differential Revision: https://reviews.llvm.org/D23929 llvm-svn: 282160
* Reapplying r281895 (and follow-up r281964) after fixing pr30468.Keith Walker2016-09-222-5/+53
| | | | | | | | | | | | | | | | The additional fix is: When adding debug information to a lowered phi node in mem2reg check that we have a valid insertion point after the phi for adding the debug information. This change addresses the issue in pr30468 where a lowered phi was added before a catchswitch and no debug information should be added after the phi in this case. Differential Revision: https://reviews.llvm.org/D24797 llvm-svn: 282155
* [RS4GC] Remat in presence of phi and use live valueAnna Thomas2016-09-221-8/+21
| | | | | | | | | | Summary: Reviewers: Subscribers: llvm-svn: 282150
* [EfficiencySanitizer] Using '$' instead of '#' for struct counter nameSagar Thakur2016-09-221-6/+6
| | | | | | | | | For MIPS '#' is the start of comment line. Therefore we get assembler errors if # is used in the structure names. Differential: D24334 Reviewed by: zhaoqin llvm-svn: 282141
* Fix revision 281960Dorit Nuzman2016-09-221-2/+4
| | | | llvm-svn: 282139
* [LoopInterchange] Track all dependencies, not just anti dependencies.Chad Rosier2016-09-211-50/+47
| | | | | | | | | | | | | | | | | Currently, we give up on loop interchange if we encounter a flow dependency anywhere in the loop list. Worse yet, we don't even track output dependencies. This patch updates the dependency matrix computation to track flow and output dependencies in the same way we track anti dependencies. This improves an internal workload by 2.2x. Note the loop interchange pass is off by default and it can be enabled with '-mllvm -enable-loopinterchange' Differential Revision: https://reviews.llvm.org/D24564 llvm-svn: 282101
* revert 281908 because 281909 got revertedNico Weber2016-09-211-46/+7
| | | | llvm-svn: 282097
* [LV] Don't emit unused scalars for uniform instructionsMatthew Simpson2016-09-211-14/+58
| | | | | | | | | | | | If we identify an instruction as uniform after vectorization, we know that we should only use the value corresponding to the first vector lane of each unroll iteration. However, when scalarizing such instructions, we still produce values for the other vector lanes. This patch prevents us from generating the unused scalars. Differential Revision: https://reviews.llvm.org/D24275 llvm-svn: 282087
* Change the basic block weight calculation algorithm to use max instead of ↵Dehao Chen2016-09-211-14/+6
| | | | | | | | | | | | | | voting. Summary: Now that we have more precise debug info, we should change back to use maximum to get basic block weight. Reviewers: dnovillo Subscribers: andreadb, llvm-commits Differential Revision: https://reviews.llvm.org/D24788 llvm-svn: 282084
* [LV] Rename "Width" to "Lane" (NFC)Matthew Simpson2016-09-211-6/+6
| | | | llvm-svn: 282083
* Revert r281895 "Add @llvm.dbg.value entries for the phi node created by ↵Hans Wennborg2016-09-212-49/+5
| | | | | | | | | | -mem2reg" (And follow-up r281964.) It caused PR30468. llvm-svn: 282077
* DeadArgElim: Don't mark swifterror arguments as unusedArnold Schwaighofer2016-09-211-1/+1
| | | | | | | | Replacing swifterror arguments with undef creates invalid IR. rdar://28300490 llvm-svn: 282075
* [LoopInterchange] Various cleanup. NFC.Chad Rosier2016-09-211-23/+19
| | | | llvm-svn: 282071
* code cleanup -- commoning IR travsersalsXinliang David Li2016-09-201-3/+5
| | | | llvm-svn: 282034
* [RS4GC] Refactor code for Rematerializing in presence of phi. NFCAnna Thomas2016-09-201-59/+68
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This is an NFC refactoring change as a precursor to the actual fix for rematerializing in presence of phi. https://reviews.llvm.org/D24399 Pasted from review: findRematerializableChainToBasePointer changed to return the root of the chain. instead of true or false. move the PHI matching logic into the caller by inspecting the root return value. This includes an assertion that the alternate root is in the liveset for the call. Tested with current RS4GC tests. Reviewers: reames, sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24780 llvm-svn: 282023
* [Profile] Do not annotate select insts not covered in profile.Xinliang David Li2016-09-201-1/+2
| | | | | | Fixed PR/30466 llvm-svn: 282009
* [Profile] code refactoring: make getStep a method in base classXinliang David Li2016-09-201-9/+1
| | | | llvm-svn: 282002
* ASAN: Don't drop debug info attachements for global variables.Adrian Prantl2016-09-201-0/+7
| | | | | | | | | | This is a follow-up to r281284. Global Variables now can have !dbg attachements, so ASAN should clone these when generating a sanitized copy of a global variable. <rdar://problem/24899262> llvm-svn: 281994
OpenPOWER on IntegriCloud