summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/IPO
Commit message (Collapse)AuthorAgeFilesLines
* LowerBitSets: Add debugging output.Peter Collingbourne2015-07-291-0/+22
| | | | | | Differential Revision: http://reviews.llvm.org/D11583 llvm-svn: 243546
* Remove unused variable. NFC.Diego Novillo2015-07-241-1/+0
| | | | llvm-svn: 243145
* Remove the user-count threshold when analyzing read attributesJingyue Wu2015-07-241-3/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: This threshold limited FunctionAttrs ability to prove arguments to be read-only. In NVPTX, a specialized instruction ld.global.nc can be used to load memory with non-coherent texture cache. We notice that in SHOC [1] benchmark, some function arguments are not marked with readonly because FunctionAttrs reaches a hardcoded threshold when analysis uses. Removing this threshold won't cause significant regression in compilation time, because the worst-case time complexity of the algorithm is still O(# of instructions) for each parameter. Patched by Xuetian Weng. [1] https://github.com/vetter/shoc Reviewers: nlewycky, jingyue, nicholas Subscribers: nicholas, test, llvm-commits Differential Revision: http://reviews.llvm.org/D11311 llvm-svn: 243141
* Use foreach loops for StructType::elements(). NFC.Pete Cooper2015-07-241-4/+4
| | | | | | | | | | | | We had a few places where we did for (unsigned i = 0, e = STy->getNumElements(); i != e; ++i) { but those could instead do for (auto *EltTy : STy->elements()) { llvm-svn: 243136
* [GMR] Add a late run of GlobalsModRef to the main pass pipeline behindChandler Carruth2015-07-231-0/+18
| | | | | | | | | | | | | | | | | | | the general GMR-in-non-LTO flag. Without this, we have the global information during the CGSCC pipeline for GVN and such, but don't have it available during the late loop optimizations such as the vectorizer. Moreover, after the CGSCC pipeline has finished we have substantially more accurate and refined call graph information, function annotations, etc, which will make GMR even more powerful than it is early in the pipelien. Note that we have to play silly games with preserving AliasAnalysis (which is now trivially preserved) in order to let a module analysis magically be preserved into the entire function pass pipeline. Simultaneously we have to not make GMR an immutable pass in order to be able to re-run it and collect fresh data on the final call graph. llvm-svn: 242999
* [PM/AA] Extract the ModRef enums from the AliasAnalysis class inChandler Carruth2015-07-222-9/+8
| | | | | | | | | | | | | | | | | | | | | | | preparation for de-coupling the AA implementations. In order to do this, they had to become fake-scoped using the traditional LLVM pattern of a leading initialism. These can't be actual scoped enumerations because they're bitfields and thus inherently we use them as integers. I've also renamed the behavior enums that are specific to reasoning about the mod/ref behavior of functions when called. This makes it more clear that they have a very narrow domain of applicability. I think there is a significantly cleaner API for all of this, but I don't want to try to do really substantive changes for now, I just want to refactor the things away from analysis groups so I'm preserving the exact original design and just cleaning up the names, style, and lifting out of the class. Differential Revision: http://reviews.llvm.org/D10564 llvm-svn: 242963
* Revert "Improve merging of stores from static constructors in GlobalOpt"Anthony Pesch2015-07-221-249/+77
| | | | | | This reverts commit 0a9dee959a30b81b9e7df64c9a58ff9898c24024. llvm-svn: 242954
* Revert "IPO: Avoid brace initialization of a map, some versions of libc++ ↵Anthony Pesch2015-07-221-4/+1
| | | | | | | | don't like it" This reverts commit fc2dad0c68f8d32273d3c2d790ed496961f829af. llvm-svn: 242953
* IPO: Avoid brace initialization of a map, some versions of libc++ don't like itJustin Bogner2015-07-221-1/+4
| | | | | | | | | Should fix the build failure on these darwin bots: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/12427/ http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/10389/ llvm-svn: 242945
* Improve merging of stores from static constructors in GlobalOptAnthony Pesch2015-07-221-77/+249
| | | | | | | | | | | | | | | | | | | Summary: While working on a project I wound up generating a fairly large lookup table (10k entries) of callbacks inside of a static constructor. Clang was taking upwards of ~10 minutes to compile the lookup table. I generated a smaller test case (http://www.inolen.com/static_initializer_test.ll) that, after running with -ftime-report, pointed fingers at GlobalOpt and MemCpyOptimizer. Running globalopt took around ~9 minutes. The slowdown came from how GlobalOpt merged stores from static constructors individually into the global initializer in EvaluateStaticConstructor. For each store it discovered and wanted to commit, it would copy the existing global initializer and then merge in the individual store. I changed this so that stores are now grouped by global, and sorted from most significant to least significant by their GEP indexes (e.g. a store to GEP 0, 0 comes before GEP 0, 0, 1). With this representation, the existing initializer can be copied and all new stores merged into it in a single pass. With this patch and http://reviews.llvm.org/D11198, the lookup table that was taking ~10 minutes to compile now compiles in around 5 seconds. I've ran 'make check' and the test-suite, which all passed. I'm not really sure who to tag as a reviewer, Lang mentioned that Chandler may be appropriate. Reviewers: chandlerc, nlewycky Subscribers: nlewycky, llvm-commits Differential Revision: http://reviews.llvm.org/D11200 llvm-svn: 242935
* Test commit, added blank lineAnthony Pesch2015-07-221-0/+1
| | | | llvm-svn: 242923
* [GMR] Add a flag to enable GlobalsModRef in the normal compilationChandler Carruth2015-07-221-0/+11
| | | | | | | | | | | | | | | pipeline. Even before I started improving its runtime, it was already crazy fast once the call graph exists, and if we can get it to be conservatively correct, will still likely catch a lot of interesting and useful cases. So it may well be useful to enable by default. But more importantly for me, this should make it easier for me to test that changes aren't breaking it in fundamental ways by enabling it for normal builds. llvm-svn: 242895
* [PM/AA] Remove the last of the legacy update API from AliasAnalysis asChandler Carruth2015-07-221-21/+1
| | | | | | | | | | | | | part of simplifying its interface and usage in preparation for porting to work with the new pass manager. Note that this will likely expose that we have dead arguments, members, and maybe even pass requirements for AA. I'll be cleaning those up in seperate patches. This just zaps the actual update API. Differential Revision: http://reviews.llvm.org/D11325 llvm-svn: 242881
* MergeFunc: Transfer the callee's attributes when replacing a direct callerArnold Schwaighofer2015-07-211-0/+19
| | | | | | | | | | We insert a bitcast which obfuscates the getCalledFunction for the utility function which looks up attributes from the called function. Loosing ABI changing parameter attributes is a bad thing. rdar://21516488 llvm-svn: 242807
* Revert "MergeFuncs: Transfer the function parameter attributes to the call site"Arnold Schwaighofer2015-07-191-1/+0
| | | | | | | | It is okay to not transfer parameter attributes. This reverts commit r242558. llvm-svn: 242646
* Narrow Callee scope, suggestion from David Blaikie.Yaron Keren2015-07-191-3/+3
| | | | llvm-svn: 242644
* De-duplicate CS.getCalledFunction() expression.Yaron Keren2015-07-191-1/+2
| | | | | | | Not sure if the optimizer will save the call as getCalledFunction() is not a trivial access function but the code is clearer this way. llvm-svn: 242641
* Rangify for loops in GlobalDCE, NFC.Yaron Keren2015-07-181-55/+49
| | | | llvm-svn: 242619
* MergeFuncs: Transfer the function parameter attributes to the call siteArnold Schwaighofer2015-07-171-0/+1
| | | | | | rdar://21516488 llvm-svn: 242558
* Internalize: internalize comdat members as a group, and drop comdat on such ↵Peter Collingbourne2015-07-161-26/+71
| | | | | | | | | | | | | | | | | | | | members. Internalizing an individual comdat group member without also internalizing the other members of the comdat can break comdat semantics. For example, if a module contains a reference to an internalized comdat member, and the linker chooses a comdat group from a different object file, this will break the reference to the internalized member. This change causes the internalizer to only internalize comdat members if all other members of the comdat are not externally visible. Once a comdat group has been fully internalized, there is no need to apply comdat rules to its members; later optimization passes (e.g. globaldce) can legally drop individual members of the comdat. So we drop the comdat attribute from all comdat members. Differential Revision: http://reviews.llvm.org/D10679 llvm-svn: 242423
* Add PM extension point EP_VectorizerStartTobias Grosser2015-07-161-0/+2
| | | | | | | This extension point allows passes to be executed right before the vectorizer and other highly target specific optimizations are run. llvm-svn: 242389
* Fix mergefunc infinite loopJF Bastien2015-07-151-2/+6
| | | | | | | | | | | | | | | Self-referential constants containing references to a merged function no longer cause the MergeFunctions pass to infinite loop. Also adds a reproduction IR which would otherwise fail, which was isolated from a similar issue in Chromium. Author: jrkoenig Reviewers: nlewycky, jfb Subscribers: llvm-commits, nlewycky, jfb Differential Revision: http://reviews.llvm.org/D11208 llvm-svn: 242337
* Remove unused variable.Rafael Espindola2015-07-131-1/+0
| | | | | | Sorry I missed it in the previous commit. llvm-svn: 242032
* Aliases don't have available_externally linkage.Rafael Espindola2015-07-131-11/+0
| | | | | | | Allowing that is probably a good idea, but currently we don't, so this is dead code. llvm-svn: 242031
* Don't change the visibility when converting a definition to a declaration.Rafael Espindola2015-07-132-3/+1
| | | | llvm-svn: 242030
* [PM/AA] Completely remove the AliasAnalysis::copyValue interface.Chandler Carruth2015-07-111-2/+0
| | | | | | | | | | | | | | | | | | | | | No in-tree alias analysis used this facility, and it was not called in any particularly rigorous way, so it seems unlikely to be correct. Note that one of the only stateful AA implementations in-tree, GlobalsModRef is completely broken currently (and any AA passes like it are equally broken) because Module AA passes are not effectively invalidated when a function pass that fails to update the AA stack runs. Ultimately, it doesn't seem like we know how we want to build stateful AA, and until then trying to support and maintain correctness for an untested API is essentially impossible. To that end, I'm planning to rip out all of the update API. It can return if and when we need it and know how to build it on top of the new pass manager and as part of *tested* stateful AA implementations in the tree. Differential Revision: http://reviews.llvm.org/D10889 llvm-svn: 241975
* Disable loop re-rotation for -Oz (patch by Andrey Turetsky)Alexey Bataev2015-07-101-2/+2
| | | | | | | After changes in rL231820 loop re-rotation is performed even in -Oz mode. Since loop rotation is disabled for -Oz, it seems loop re-rotation should be disabled too. Differential Revision: http://reviews.llvm.org/D10961 llvm-svn: 241897
* [llvm-extract] Drop comdats from declarationsReid Kleckner2015-07-061-2/+8
| | | | | | The verifier rejects comdats on declarations. llvm-svn: 241483
* Resubmit "Add new EliminateAvailableExternally module pass" (r239480)Teresa Johnson2015-07-063-0/+112
| | | | | | | | | | | | | | | | | | | | | | This change includes a fix for https://code.google.com/p/chromium/issues/detail?id=499508#c3, which required updating the visibility for symbols with eliminated definitions. --Original Commit Message-- Add new EliminateAvailableExternally module pass, which is performed in O2 compiles just before GlobalDCE, unless we are preparing for LTO. This pass eliminates available externally globals (turning them into declarations), regardless of whether they are dead/unreferenced, since we are guaranteed to have a copy available elsewhere at link time. This enables additional opportunities for GlobalDCE. If we are preparing for LTO (e.g. a -flto -c compile), the pass is not included as we want to preserve available externally functions for possible link time inlining. The FE indicates whether we are doing an -flto compile via the new PrepareForLTO flag on the PassManagerBuilder. llvm-svn: 241466
* IR: Do not consider available_externally linkage to be linker-weak.Peter Collingbourne2015-07-051-14/+12
| | | | | | | | | | | | | | | From the linker's perspective, an available_externally global is equivalent to an external declaration (per isDeclarationForLinker()), so it is incorrect to consider it to be a weak definition. Also clean up some logic in the dead argument elimination pass and clarify its comments to better explain how its behavior depends on linkage, introduce GlobalValue::isStrongDefinitionForLinker() and start using it throughout the optimizers and backend. Differential Revision: http://reviews.llvm.org/D10941 llvm-svn: 241413
* Remove whitespace from start of line, NFC.Yaron Keren2015-07-021-2/+2
| | | | llvm-svn: 241268
* [PruneEH] A naked, noinline function can return via InlineAsmDavid Majnemer2015-06-271-25/+38
| | | | | | | | | | The PruneEH pass tries to annotate functions as 'noreturn' if it doesn't see a ReturnInst. However, a naked function containing inline assembly can contain control flow leaving the function. This fixes PR23971. llvm-svn: 240876
* LowerBitSets: Ignore bitset entries that do not directly refer to a global.Peter Collingbourne2015-06-271-3/+7
| | | | | | | | | | | | | | | | | It is possible for a global to be substituted with another global of a different type or a different kind (i.e. an alias) at IR link time. One example of this scenario is when a Microsoft ABI vtable is substituted with an alias referring to a larger vtable containing an RTTI reference. This will cause the global to be RAUW'd with a possibly bitcasted reference to the other global. This will of course also affect any references to the global in bitset metadata. The right way to handle such metadata is simply to ignore it. This is sound because the linked module should contain another copy of the bitset entries as applied to the new global. llvm-svn: 240866
* Use foreach loop over constant operands. NFC.Pete Cooper2015-06-252-7/+5
| | | | | | | A number of places had explicit loops over Constant::operands(). Just use foreach loops where possible. llvm-svn: 240694
* Rangify for loop in Inliner.cpp. NFC.Yaron Keren2015-06-251-8/+5
| | | | llvm-svn: 240678
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-2315-20/+20
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
* Rangify for loops in Inliner::runOnSCC(), NFC.Yaron Keren2015-06-201-11/+9
| | | | llvm-svn: 240215
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-1915-20/+20
| | | | | | | | | | | | | The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-172-1/+4
| | | | | | | | | | | | | | | | | | | The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
* LowerBitSets: Do not assign names to aliases of unnamed bitset element objects.Peter Collingbourne2015-06-171-3/+2
| | | | | | | The restriction on unnamed aliases was removed in r239921. Mostly reverts r239590, but we keep the test. llvm-svn: 239923
* [PM/AA] Remove the UnknownSize static member from AliasAnalysis.Chandler Carruth2015-06-171-1/+1
| | | | | | | | This is now living in MemoryLocation, which is what it pertains to. It is also an enum there rather than a static data member which is left never defined. llvm-svn: 239886
* [PM/AA] Remove the Location typedef from the AliasAnalysis class nowChandler Carruth2015-06-172-6/+5
| | | | | | | | | | | | that it is its own entity in the form of MemoryLocation, and update all the callers. This is an entirely mechanical change. References to "Location" within AA subclases become "MemoryLocation", and elsewhere "AliasAnalysis::Location" becomes "MemoryLocation". Hope that helps out-of-tree folks update. llvm-svn: 239885
* Protection against stack-based memory corruption errors using SafeStackPeter Collingbourne2015-06-151-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the safe stack instrumentation pass to LLVM, which separates the program stack into a safe stack, which stores return addresses, register spills, and local variables that are statically verified to be accessed in a safe way, and the unsafe stack, which stores everything else. Such separation makes it much harder for an attacker to corrupt objects on the safe stack, including function pointers stored in spilled registers and return addresses. You can find more information about the safe stack, as well as other parts of or control-flow hijack protection technique in our OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf) and our project website (http://levee.epfl.ch). The overhead of our implementation of the safe stack is very close to zero (0.01% on the Phoronix benchmarks). This is lower than the overhead of stack cookies, which are supported by LLVM and are commonly used today, yet the security guarantees of the safe stack are strictly stronger than stack cookies. In some cases, the safe stack improves performance due to better cache locality. Our current implementation of the safe stack is stable and robust, we used it to recompile multiple projects on Linux including Chromium, and we also recompiled the entire FreeBSD user-space system and more than 100 packages. We ran unit tests on the FreeBSD system and many of the packages and observed no errors caused by the safe stack. The safe stack is also fully binary compatible with non-instrumented code and can be applied to parts of a program selectively. This patch is our implementation of the safe stack on top of LLVM. The patches make the following changes: - Add the safestack function attribute, similar to the ssp, sspstrong and sspreq attributes. - Add the SafeStack instrumentation pass that applies the safe stack to all functions that have the safestack attribute. This pass moves all unsafe local variables to the unsafe stack with a separate stack pointer, whereas all safe variables remain on the regular stack that is managed by LLVM as usual. - Invoke the pass as the last stage before code generation (at the same time the existing cookie-based stack protector pass is invoked). - Add unit tests for the safe stack. Original patch by Volodymyr Kuznetsov and others at the Dependable Systems Lab at EPFL; updates and upstreaming by myself. Differential Revision: http://reviews.llvm.org/D6094 llvm-svn: 239761
* LowerBitSets: Give names to aliases of unnamed bitset element objects.Peter Collingbourne2015-06-121-2/+3
| | | | | | | | It is valid for globals to be unnamed, but aliases must have a name. To avoid creating invalid IR, we need to assign names to any aliases we create that point to unnamed objects that have been moved into combined globals. llvm-svn: 239590
* Revert commit r239480 as it causes ↵Teresa Johnson2015-06-123-109/+0
| | | | | | https://code.google.com/p/chromium/issues/detail?id=499508#c3. llvm-svn: 239589
* ArgumentPromotion: Drop sret attribute on functions that are only called ↵Peter Collingbourne2015-06-101-0/+18
| | | | | | | | | | | | | | | | | | | directly. If the first argument to a function is a 'this' argument and the second has the sret attribute, the ArgumentPromotion pass may promote the 'this' argument to more than one argument, violating the IR constraint that 'sret' may only be applied to the first or second argument. Although this IR constraint is arguably unnecessary, it highlighted the fact that ArgPromotion does not need to preserve this attribute. Dropping the attribute reduces register pressure in the backend by avoiding the register copy required by sret. Because sret implies noalias, we also replace the former with the latter. Differential Revision: http://reviews.llvm.org/D10353 llvm-svn: 239488
* Add new EliminateAvailableExternally module pass, which is performed inTeresa Johnson2015-06-103-0/+109
| | | | | | | | | | | | | | | | O2 compiles just before GlobalDCE, unless we are preparing for LTO. This pass eliminates available externally globals (turning them into declarations), regardless of whether they are dead/unreferenced, since we are guaranteed to have a copy available elsewhere at link time. This enables additional opportunities for GlobalDCE. If we are preparing for LTO (e.g. a -flto -c compile), the pass is not included as we want to preserve available externally functions for possible link time inlining. The FE indicates whether we are doing an -flto compile via the new PrepareForLTO flag on the PassManagerBuilder. llvm-svn: 239480
* Remove DisableTailCalls from TargetOptions and the code in resetTargetOptionsAkira Hatanaka2015-06-091-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | that was resetting it. Remove the uses of DisableTailCalls in subclasses of TargetLowering and use the value of function attribute "disable-tail-calls" instead. Also, unconditionally add pass TailCallElim to the pipeline and check the function attribute at the start of runOnFunction to disable the pass on a per-function basis. This is part of the work to remove TargetMachine::resetTargetOptions, and since DisableTailCalls was the last non-fast-math option that was being reset in that function, we should be able to remove the function entirely after the work to propagate IR-level fast-math flags to DAG nodes is completed. Out-of-tree users should remove the uses of DisableTailCalls and make changes to attach attribute "disable-tail-calls"="true" or "false" to the functions in the IR. rdar://problem/13752163 Differential Revision: http://reviews.llvm.org/D10099 llvm-svn: 239427
* MergeFunctions: Don't replace a weak function use by another equivalent weak ↵Arnold Schwaighofer2015-06-091-15/+13
| | | | | | | | | | function We don't know whether the weak functions definition is the definitive definition. rdar://21303727 llvm-svn: 239422
* MergeFunctions: Fix gcc warning in conditionDenis Protivensky2015-06-091-2/+2
| | | | llvm-svn: 239391
OpenPOWER on IntegriCloud