summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* [RewriteStatepointsForGC] All constant should have null base pointerIgor Laevsky2016-05-271-8/+16
| | | | | | | | | | | | | | | | | | Currently we consider that each constant has itself as a base value. I.e "base(const) = const". This introduces couple of problems when we are trying to avoid reporting constants in statepoint live sets: 1. When querying "base( phi(const1, const2) )" we will get "phi(const1, const2)" as a base pointer. Since it's not a constant we will record it in a stack map. However on practice we don't want this to happen (constant are never relocated). 2. base( phi(const, gc ptr) ) = phi( const, base(gc ptr) ). This particular case imposes challenge on our runtime - we don't expect to see constant base pointers other than null. This problems can be avoided by treating all constant as if they were derived from null pointer base. I.e in a first case we will not include constant pointer in a stack map at all. In a second case we will get "phi(null, base(gc ptr))" as a base pointer which is a lot more convenient. Differential Revision: http://reviews.llvm.org/D20584 llvm-svn: 270993
* Avoid some copies by using const references.Benjamin Kramer2016-05-272-5/+5
| | | | | | | clang-tidy's performance-unnecessary-copy-initialization with some manual fixes. No functional changes intended. llvm-svn: 270988
* Revert: r270973 - [X86][SSE] Replace (V)PMOVSX and (V)PMOVZX integer ↵Simon Pilgrim2016-05-271-0/+44
| | | | | | extension intrinsics with generic IR (llvm) llvm-svn: 270976
* [X86][SSE] Replace (V)PMOVSX and (V)PMOVZX integer extension intrinsics with ↵Simon Pilgrim2016-05-271-44/+0
| | | | | | | | | | | | generic IR (llvm) This patch removes the llvm intrinsics VPMOVSX and (V)PMOVZX sign/zero extension intrinsics and auto-upgrades to SEXT/ZEXT calls instead. We already did this for SSE41 PMOVSX sometime ago so much of that implementation can be reused. A companion patch (D20684) removes/auto-upgrade the clang intrinsics. Differential Revision: http://reviews.llvm.org/D20686 llvm-svn: 270973
* Form objc_storeStrong in the presence of bitcasts.Pete Cooper2016-05-271-1/+2
| | | | | | | | | | | | | | | | objc_storeStrong can be formed from a sequence such as %0 = tail call i8* @objc_retain(i8* %p) nounwind %tmp = load i8*, i8** @x, align 8 store i8* %0, i8** @x, align 8 tail call void @objc_release(i8* %tmp) nounwind The code was already looking through bitcasts for most of the values involved, but had missed one case where the pointer operand for the store was a bitcast. Ultimately the pointer for the load and store have to be the same value, after stripping casts. llvm-svn: 270955
* ValueMapper: fix typo in minor optimization on constant mapping (NFC)Mehdi Amini2016-05-271-1/+2
| | | | | | | | | | | | | | | | | If every operands of a constant are mapping to themselves, and the type does not change, we have an early exit as acknowledged in the comment: // Otherwise, we have some other constant to remap. Start by checking to see // if all operands have an identity remapping. However instead of checking for identity the code was checking if the operands were mapped to the constant itself, which is rarely true. As a consequence, the coverage report showed that the early exit was never taken. llvm-svn: 270944
* Attach profile summary in IR based instrumentation pass.Easwaran Raman2016-05-261-1/+8
| | | | | | Differential revision: http://reviews.llvm.org/D20655 llvm-svn: 270933
* [LoopUnrollAnalyzer] Fix a crash in analyzeLoopUnrollCost.Michael Zolotukhin2016-05-261-20/+16
| | | | | | | | | Condition might be simplified to a Constant, but it doesn't have to be ConstantInt, so we should dyn_cast, instead of cast. This fixes PR27886. llvm-svn: 270924
* [MemCpyOpt] Don't perform callslot optimization across may-throw callsDavid Majnemer2016-05-261-1/+13
| | | | | | | | | An exception could prevent a store from occurring but MemCpyOpt's callslot optimization would fire anyway, causing the store to occur. This fixes PR27849. llvm-svn: 270892
* [BBVectorize] Don't vectorize selects with a scalar condition and vector ↵Michael Kuperstein2016-05-261-1/+8
| | | | | | | | | | operands. This fixes PR27879. Differential Revision: http://reviews.llvm.org/D20659 llvm-svn: 270888
* Revert 270865 -- unexplained bot failure on linux/ppcleXinliang David Li2016-05-261-1/+1
| | | | llvm-svn: 270876
* Use new interface in Triple /NFCXinliang David Li2016-05-261-1/+1
| | | | llvm-svn: 270865
* [InstCombine] Catch more bswap cases missed due to zext and truncs.Chad Rosier2016-05-262-18/+76
| | | | | | | Fixes PR27824. Differential Revision: http://reviews.llvm.org/D20591. llvm-svn: 270853
* Add auto-exporting of symbols from tools so that plugins work on WindowsJohn Brawn2016-05-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem with plugins on Windows is that when building a plugin DLL it needs to explicitly link against something (an exe or DLL) if it uses symbols from that thing, and that thing must explicitly export those symbols. Also there's a limit of 65535 symbols that can be exported. This means that currently plugins only work on Windows when using BUILD_SHARED_LIBS, and that doesn't work with MSVC. This patch adds an LLVM_EXPORT_SYMBOLS_FOR_PLUGINS option, which when enabled automatically exports from all LLVM tools the symbols that a plugin could want to use so that a plugin can link against a tool directly. Plugins can specify what tool they link against by using PLUGIN_TOOL argument to llvm_add_library. The option can also be enabled on Linux, though there all it should do is restrict the set of symbols that are exported as by default all symbols are exported. This option is currently OFF by default, as while I've verified that it works with MSVC, linux gcc, and cygwin gcc, I haven't tried mingw gcc and I have no idea what will happen on OSX. Also unfortunately we can't turn on LLVM_ENABLE_PLUGINS when the option is ON as bugpoint-passes needs to be loaded by both bugpoint.exe and opt.exe which is incompatible with this approach. Also currently clang plugins don't work with this approach, which will be fixed in future patches. Differential Revision: http://reviews.llvm.org/D18826 llvm-svn: 270839
* [MergedLoadStoreMotion] Don't transform across may-throw callsDavid Majnemer2016-05-261-24/+32
| | | | | | | | | | | | It is unsafe to hoist a load before a function call which may throw, the throw might prevent a pointer dereference. Likewise, it is unsafe to sink a store after a call which may throw. The caller might be able to observe the difference. This fixes PR27858. llvm-svn: 270828
* [MergedLoadStoreMotion] Small cleanupDavid Majnemer2016-05-261-57/+45
| | | | | | No functional change is intended. llvm-svn: 270824
* MemorySSA: Revert r269678 and r268068; replace with special casing in MemorySSA.Peter Collingbourne2016-05-261-0/+8
| | | | | | | | | | | | | It turns out that too many passes are relying on alias analysis results for control dependencies. Until we fix that by introducing a more accurate modelling of control dependencies, special case assume in MemorySSA instead. Also introduce tests to ensure we don't regress the FunctionAttrs or LICM passes. Differential Revision: http://reviews.llvm.org/D20658 llvm-svn: 270823
* [X86] Add the AVX storeu intrinsics to InstCombine and LoopStrengthReduce in ↵Craig Topper2016-05-262-0/+19
| | | | | | | | the same places that the SSE/SSE2 storeu intrinsics appear. I don't really know how to test this. Just seemed like we should be consistent. llvm-svn: 270819
* [IRCE] Use C++11 style initializers; NFCSanjoy Das2016-05-261-9/+5
| | | | llvm-svn: 270815
* MemorySSA: Remove argument to createNewAccess function.Peter Collingbourne2016-05-261-4/+3
| | | | | | | | There is only one caller of MemorySSA::createNewAccess, and it passes true as the IgnoreNonMemory argument. Remove that argument and fold its behavior into createNewAccess. llvm-svn: 270812
* [IRCE] Optimize conjunctions of range checksSanjoy Das2016-05-261-51/+69
| | | | | | | | | | | | | After this change, we do the expected thing for cases like ``` Check0Passed = /* range check IRCE can optimize */ Check1Passed = /* range check IRCE can optimize */ if (!(Check0Passed && Check1Passed)) throw_Exception(); ``` llvm-svn: 270804
* [IRCE] Refactor out a parseRangeCheckFromCond; NFCSanjoy Das2016-05-261-50/+39
| | | | | | | This will later hold more general logic to parse conjunctions of range checks. llvm-svn: 270802
* [PM] Port PartiallyInlineLibCalls to the new pass manager.Davide Italiano2016-05-252-39/+55
| | | | llvm-svn: 270798
* Move whole-program virtual call optimization pass after function attribute ↵Peter Collingbourne2016-05-251-24/+27
| | | | | | | | | | | | | | | | | | inference in LTO pipeline. As a result of D18634 we no longer infer certain attributes on linkonce_odr functions at compile time, and may only infer them at LTO time. The readnone attribute in particular is required for virtual constant propagation (part of whole-program virtual call optimization) to work correctly. This change moves the whole-program virtual call optimization pass after the function attribute inference passes, and enables the attribute inference passes at opt level 1, so that virtual constant propagation has a chance to work correctly for linkonce_odr functions. Differential Revision: http://reviews.llvm.org/D20643 llvm-svn: 270765
* fix typo; NFCSanjay Patel2016-05-251-1/+1
| | | | llvm-svn: 270760
* ValueMaterializer: rename materializeDeclFor() to materialize()Mehdi Amini2016-05-251-3/+3
| | | | | | | | | | It may materialize a declaration, or a definition. The name could be misleading. This is following a merge of materializeInitFor() into materializeDeclFor(). Differential Revision: http://reviews.llvm.org/D20593 llvm-svn: 270759
* ValueMaterializer: fuse materializeDeclFor and materializeInitFor (NFC)Mehdi Amini2016-05-251-7/+1
| | | | | | | | | | | | They were originally separated to handle the co-recursion between the ValueMapper and the ValueMaterializer. This recursion does not exist anymore: the ValueMapper now uses a Worklist and the ValueMaterializer is scheduling job on the Worklist. Differential Revision: http://reviews.llvm.org/D20593 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 270758
* [PM] CorrelatedValuePropagation: pass state to function. NFCI.Davide Italiano2016-05-251-29/+16
| | | | | | | While here, convert the logic of the pass to use static function(s). This is in preparation for porting this pass to the new PM. llvm-svn: 270734
* Use new triple API to check if comdat is supportedXinliang David Li2016-05-251-1/+1
| | | | llvm-svn: 270727
* Clarify that we match BSwap in InstCombine and BitReverse in CGP. NFC.Chad Rosier2016-05-253-7/+7
| | | | | | | | Also, rename recognizeBitReverseOrBSwapIdiom to recognizeBSwapOrBitReverseIdiom, so the ordering of the MatchBSwaps and MatchBitReversals arguments are consistent with the function name. llvm-svn: 270715
* [ThinLTO] Refactor ODR resolution and internalization (NFC)Teresa Johnson2016-05-251-0/+77
| | | | | | | | | Move the now index-based ODR resolution and internalization routines out of ThinLTOCodeGenerator.cpp and into either LTO.cpp (index-based analysis) or FunctionImport.cpp (index-driven optimizations). This is to enable usage by other linkers. llvm-svn: 270698
* [X86][SSE] Replace (V)CVTDQ2PD(Y) and (V)CVTPS2PD(Y) lossless conversion ↵Simon Pilgrim2016-05-251-2/+0
| | | | | | | | | | intrinsics with generic IR Followup to D20528 clang patch, this removes the (V)CVTDQ2PD(Y) and (V)CVTPS2PD(Y) llvm intrinsics and auto-upgrades to sitofp/fpext instead. Differential Revision: http://reviews.llvm.org/D20568 llvm-svn: 270678
* [X86] Remove the llvm.x86.sse2.storel.dq intrinsic. It hasn't been used in a ↵Craig Topper2016-05-251-2/+0
| | | | | | long time. llvm-svn: 270677
* [FunctionAttrs] Volatile loads should disable readonlyDavid Majnemer2016-05-251-0/+5
| | | | | | | | A volatile load has side effects beyond what callers expect readonly to signify. For example, it is not safe to reorder two function calls which each perform a volatile load to the same memory location. llvm-svn: 270671
* [PM] Port BDCE to the new pass manager.Davide Italiano2016-05-252-34/+40
| | | | llvm-svn: 270647
* [esan|wset] EfficiencySanitizer working set tool fastpathDerek Bruening2016-05-251-0/+104
| | | | | | | | | | | | | | | | | Summary: Adds fastpath instrumentation for esan's working set tool. The instrumentation for an intra-cache-line load or store consists of an inlined write to shadow memory bits for the corresponding cache line. Adds a basic test for this instrumentation. Reviewers: aizatsky Subscribers: vitalybuka, zhaoqin, kcc, eugenis, llvm-commits Differential Revision: http://reviews.llvm.org/D20483 llvm-svn: 270640
* Re-enable "[LoopUnroll] Enable advanced unrolling analysis by default" one ↵Michael Zolotukhin2016-05-241-3/+3
| | | | | | | | more time. This reverts commit r270577. llvm-svn: 270630
* [esan] Add calls from the ctor/dtor to the runtime libraryDerek Bruening2016-05-241-5/+42
| | | | | | | | | | | | | | | | | | | | | Summary: Adds createEsanInitToolGV for creating a tool-specific variable passed to the runtime library. Adds dtor "esan.module_dtor" and inserts calls from the dtor to "__esan_exit" in the runtime library. Updates the EfficiencySanitizer test. Patch by Qin Zhao. Reviewers: aizatsky Subscribers: bruening, kcc, vitalybuka, eugenis, llvm-commits Differential Revision: http://reviews.llvm.org/D20488 llvm-svn: 270627
* [GuardWidening] Tighten the interface of the RangeCheck struct; NFCSanjoy Das2016-05-241-32/+37
| | | | | | Make `GuardWideningImpl::RangeCheck` into a class and add accessors. llvm-svn: 270611
* [profile] Fix runtime hook linkage bug for COFFXinliang David Li2016-05-241-0/+2
| | | | | | | | | Patch by: Johan Engelen the user hook has linkonceODR linkage and it needs to be in comdatAny group. llvm-svn: 270596
* [IRCE] Return a Value*, not SCEV* from parseRangeCheck; NFCSanjoy Das2016-05-241-26/+10
| | | | | | | This is better layering, since the caller needs to check if the index was an add-rec anyway. llvm-svn: 270582
* fix typos; NFCSanjay Patel2016-05-241-11/+11
| | | | llvm-svn: 270579
* Revert r270518, which re-enabled "[LoopUnroll] Enable advanced unrolling ↵Hans Wennborg2016-05-241-3/+3
| | | | | | | | analysis by default. Chromium builds are still hitting the assert in PR27874. llvm-svn: 270577
* Revert "Revert r270478 "[LoopUnroll] Enable advanced unrolling analysis by ↵Michael Zolotukhin2016-05-241-3/+3
| | | | | | | | | default."" This reverts commit r270512 and reapplies r270478. Originally it caused PR27847, but it was fixed in r270517. llvm-svn: 270518
* Revert r270478 "[LoopUnroll] Enable advanced unrolling analysis by default."Hans Wennborg2016-05-231-3/+3
| | | | | | This caused PR27847. llvm-svn: 270512
* [IRCE] Optimize "uses" not branches; NFCISanjoy Das2016-05-231-9/+10
| | | | | | | | | | This changes IRCE to optimize uses, and not branches. This change is NFCI since the uses we do inspect are in practice only ever going to be the condition use in conditional branches; but this flexibility will later allow us to analyze more complex expressions than just a direct branch on a range check. llvm-svn: 270500
* Avoid including AlwaysInliner pass in opt-bisect search.Andrew Kaylor2016-05-232-0/+6
| | | | | | Differential Revision: http://reviews.llvm.org/D19640 llvm-svn: 270495
* tune lowering parameter for small apps (sjeng)Xinliang David Li2016-05-231-2/+3
| | | | llvm-svn: 270480
* [InstCombine] Fix assertion when bitcast is converted to gepGerolf Hoflehner2016-05-231-0/+7
| | | | | | | | | | When an aggregate contains an opaque type its size cannot be determined. This triggers an "Invalid GetElementPtrInst indices for type" assert in function checkGEPType. The fix suppresses the conversion in this case. http://reviews.llvm.org/D20319 llvm-svn: 270479
* [LoopUnroll] Enable advanced unrolling analysis by default.Michael Zolotukhin2016-05-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch turns on LoopUnrollAnalyzer by default. To mitigate compile time regressions, I chose very conservative thresholds for now. Later we can make them more aggressive, but it might require being smarter in which loops we're optimizing. E.g. currently the biggest issue is that with more agressive thresholds we unroll many cold loops, which increases compile time for no performance benefit (performance of those loops is improved, but it doesn't matter since they are cold). Test results for compile time(using 4 samples to reduce noise): ``` MultiSource/Benchmarks/VersaBench/ecbdes/ecbdes 5.19% SingleSource/Benchmarks/Polybench/medley/reg_detect/reg_detect 4.19% MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow 3.39% MultiSource/Applications/JM/lencod/lencod 1.47% MultiSource/Benchmarks/Fhourstones-3_1/fhourstones3_1 -6.06% ``` I didn't see any performance changes in the testsuite, but it improves some internal tests. Reviewers: hfinkel, chandlerc Subscribers: llvm-commits, mzolotukhin Differential Revision: http://reviews.llvm.org/D20482 llvm-svn: 270478
OpenPOWER on IntegriCloud