summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar/SROA.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Allow DataLayout to specify addrspace for allocas.Matt Arsenault2017-04-101-5/+9
| | | | | | | | | | | | | | | | | | | | | | | LLVM makes several assumptions about address space 0. However, alloca is presently constrained to always return this address space. There's no real way to avoid using alloca, so without this there is no way to opt out of these assumptions. The problematic assumptions include: - That the pointer size used for the stack is the same size as the code size pointer, which is also the maximum sized pointer. - That 0 is an invalid, non-dereferencable pointer value. These are problems for AMDGPU because alloca is used to implement the private address space, which uses a 32-bit index as the pointer value. Other pointers are 64-bit and behave more like LLVM's notion of generic address space. By changing the address space used for allocas, we can change our generic pointer type to be LLVM's generic pointer type which does have similar properties. llvm-svn: 299888
* [Mem2Reg] Remove AliasSetTracker updating logic from the pass.Davide Italiano2017-04-091-1/+1
| | | | | | No caller has been passing it for a long time. llvm-svn: 299827
* Preserve nonnull metadata on Loads through SROA & mem2reg.Luqman Aden2017-03-221-0/+4
| | | | | | | | | | | | | | | | | Summary: https://llvm.org/bugs/show_bug.cgi?id=31142 : SROA was dropping the nonnull metadata on loads from allocas that got optimized out. This patch simply preserves nonnull metadata on loads through SROA and mem2reg. Reviewers: chandlerc, efriedma Reviewed By: efriedma Subscribers: hfinkel, spatel, efriedma, arielb1, davide, llvm-commits Differential Revision: https://reviews.llvm.org/D27114 llvm-svn: 298540
* [PM] Introduce an analysis set used to preserve all analyses overChandler Carruth2017-01-151-2/+1
| | | | | | | | | | | | | | | a function's CFG when that CFG is unchanged. This allows transformation passes to simply claim they preserve the CFG and analysis passes to check for the CFG being preserved to remove the fanout of all analyses being listed in all passes. I've gone through and removed or cleaned up as many of the comments reminding us to do this as I could. Differential Revision: https://reviews.llvm.org/D28627 llvm-svn: 292054
* "Use" lambda captures which are otherwise only used in asserts. NFCDavid L. Jones2017-01-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The LLVM coding standards recommend "using" values that are only needed by asserts: http://llvm.org/docs/CodingStandards.html#assert-liberally Without this change, LLVM cannot bootstrap with -Werror as the second stage fails with this new warning: https://reviews.llvm.org/rL291905 See also the previous fixes: https://reviews.llvm.org/rL291916 https://reviews.llvm.org/rL291939 https://reviews.llvm.org/rL291940 https://reviews.llvm.org/rL291941 Reviewers: rsmith Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28695 llvm-svn: 291957
* Refactor the DIExpression fragment query interface (NFC)Adrian Prantl2016-12-221-4/+4
| | | | | | ... so it becomes available to DIExpressionCursor. llvm-svn: 290322
* Revert @llvm.assume with operator bundles (r289755-r289757)Daniel Jasper2016-12-191-4/+11
| | | | | | | This creates non-linear behavior in the inliner (see more details in r289755's commit thread). llvm-svn: 290086
* Remove the AssumptionCacheHal Finkel2016-12-151-11/+4
| | | | | | | | | After r289755, the AssumptionCache is no longer needed. Variables affected by assumptions are now found by using the new operand-bundle-based scheme. This new scheme is more computationally efficient, and also we need much less code... llvm-svn: 289756
* [DIExpression] Introduce a dedicated DW_OP_LLVM_fragment operationAdrian Prantl2016-12-051-20/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | so we can stop using DW_OP_bit_piece with the wrong semantics. The entire back story can be found here: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161114/405934.html The gist is that in LLVM we've been misinterpreting DW_OP_bit_piece's offset field to mean the offset into the source variable rather than the offset into the location at the top the DWARF expression stack. In order to be able to fix this in a subsequent patch, this patch introduces a dedicated DW_OP_LLVM_fragment operation with the semantics that we used to apply to DW_OP_bit_piece, which is what we actually need while inside of LLVM. This patch is complete with a bitcode upgrade for expressions using the old format. It does not yet fix the DWARF backend to use DW_OP_bit_piece correctly. Implementation note: We discussed several options for implementing this, including reserving a dedicated field in DIExpression for the fragment size and offset, but using an custom operator at the end of the expression works just fine and is more efficient because we then only pay for it when we need it. Differential Revision: https://reviews.llvm.org/D27361 rdar://problem/29335809 llvm-svn: 288683
* IR: Move NumElements field from {Array,Vector}Type to SequentialType.Peter Collingbourne2016-12-021-7/+2
| | | | | | | | | | Now that PointerType is no longer a SequentialType, all SequentialTypes have an associated number of elements, so we can move that information to the base class, allowing for a number of simplifications. Differential Revision: https://reviews.llvm.org/D27122 llvm-svn: 288464
* IR: Change PointerType to derive from Type rather than SequentialType.Peter Collingbourne2016-12-021-4/+0
| | | | | | | | | | | | | | | | | | | As proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-October/106640.html This is for a couple of reasons: - Values of type PointerType are unlike the other SequentialTypes (arrays and vectors) in that they do not hold values of the element type. By moving PointerType we can unify certain aspects of how the other SequentialTypes are handled. - PointerType will have no place in the SequentialType hierarchy once pointee types are removed, so this is a necessary step towards removing pointee types. Differential Revision: https://reviews.llvm.org/D26595 llvm-svn: 288462
* IR: Change the gep_type_iterator API to avoid always exposing the "current" ↵Peter Collingbourne2016-12-021-1/+1
| | | | | | | | | | | | | type. Instead, expose whether the current type is an array or a struct, if an array what the upper bound is, and if a struct the struct type itself. This is in preparation for a later change which will make PointerType derive from Type rather than SequentialType. Differential Revision: https://reviews.llvm.org/D26594 llvm-svn: 288458
* [SROA] Drop lifetime.start/end intrinsics when they block promotion.Eli Friedman2016-11-281-6/+12
| | | | | | | | | | | | | | Preserving lifetime markers isn't as important as allowing promotion, so just drop the lifetime markers if necessary. This also fixes an assertion failure where other parts of SROA assumed that lifetime markers never block promotion. Fixes https://llvm.org/bugs/show_bug.cgi?id=29139. Differential Revision: https://reviews.llvm.org/D24854 llvm-svn: 288074
* Remove TimeValue usage from Scalar/SROA.cpp. NFC.Pavel Labath2016-11-091-2/+3
| | | | llvm-svn: 286361
* Use StringRef in Pass/PassManager APIs (NFC)Mehdi Amini2016-10-011-1/+1
| | | | llvm-svn: 283004
* Fix revision 281960Dorit Nuzman2016-09-221-2/+4
| | | | llvm-svn: 282139
* Reverting revision 281960 due to test failures.Dorit Nuzman2016-09-201-10/+2
| | | | llvm-svn: 281961
* [SROA] Preserve llvm.mem.parallel_loop_access metadata.Dorit Nuzman2016-09-201-2/+10
| | | | | | | | | | | | SROA doesn't preserve the llvm.mem.parallel_loop_access metadata when it transforms loads/stores. This patch fixes a couple occurences of this issue. (Partially addresses PR28981). Differential Revision: https://reviews.llvm.org/D23549 llvm-svn: 281960
* [SROA] Remove incorrect assertionJames Molloy2016-08-221-3/+0
| | | | | | | | | Confirmed with aprantl, this assertion is incorrect - code can get here (for example 80-bit FP types) and if it does it's benign. This is exposed by a completely unrelated patch of mine, so stop the compiler falling over. Original differential: http://reviews.llvm.org/D16187 aprantl's advice to remove assertion: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160815/382129.html llvm-svn: 279454
* Use the range variant of remove_if instead of unpacking begin/endDavid Majnemer2016-08-121-63/+53
| | | | | | No functionality change is intended. llvm-svn: 278475
* Use range algorithms instead of unpacking begin/endDavid Majnemer2016-08-111-11/+10
| | | | | | No functionality change is intended. llvm-svn: 278417
* Consistently use FunctionAnalysisManagerSean Silva2016-08-091-1/+1
| | | | | | | | | | | Besides a general consistently benefit, the extra layer of indirection allows the mechanical part of https://reviews.llvm.org/D23256 that requires touching every transformation and analysis to be factored out cleanly. Thanks to David for the suggestion. llvm-svn: 278077
* [SROA] Fix crash with lifetime intrinsic partially covering alloca.Eli Friedman2016-08-081-1/+7
| | | | | | | | | | | | | Summary: PromoteMemToReg looks specifically for the pattern bitcast+lifetime.start (or a bitcast-equivalent GEP); any offset will lead to an assertion failure. Fixes https://llvm.org/bugs/show_bug.cgi?id=27999 . Differential Revision: https://reviews.llvm.org/D22737 llvm-svn: 277969
* Fix formatting of r273144. NFC.Patrik Hagglund2016-06-201-4/+4
| | | | llvm-svn: 273149
* Avoid output indeterminism between GCC and Clang builds.Patrik Hagglund2016-06-201-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove dependency of the evalution order of function arguments, which is unspecified. The following test previously failed when built with GCC (but succeded when built with Clang): ; RUN: opt -sroa -S < %s | FileCheck %s target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" %A = type {i16} @a = global %A* null @b = global i16 0 ; CHECK-LABEL: @f1( ; CHECK: alloca %A ; CHECK-NEXT: extractvalue %A ; CHECK-NEXT: getelementptr inbounds %A define void @f1 (%A %a) { %1 = alloca %A store %A %a, %A* %1 %2 = load i16, i16* @b %3 = icmp ne i16 %2, 0 br i1 %3, label %bb1, label %bb2 bb1: store %A* %1, %A** @a br label %bb2 bb2: ret void } Patch by David Stenberg. Differential Revision: http://reviews.llvm.org/D21226 llvm-svn: 273144
* [PM] Preserve GlobalsAA for SROA.Davide Italiano2016-06-071-1/+6
| | | | | | Differential Revision: http://reviews.llvm.org/D21040 llvm-svn: 272009
* [SROA] Function canConvertValue needs to check whether both NewTy and OldTy ↵Jack Liu2016-05-031-2/+4
| | | | | | | | | | | pointers are pointing to the same addr space. This can prevent SROA from creating a bitcast between pointers with different addr spaces. Differential Revision: http://reviews.llvm.org/D19697 llvm-svn: 268424
* Revert 268409 due to missing comment.Jack Liu2016-05-031-4/+2
| | | | llvm-svn: 268421
* (no commit message)Jack Liu2016-05-031-2/+4
| | | | llvm-svn: 268409
* isSafeToLoadUnconditionally support queries without a contextArtur Pilipenko2016-04-271-3/+6
| | | | | | | | | | This is required to use this function from isSafeToSpeculativelyExecute Reviewed By: hfinkel Differential Revision: http://reviews.llvm.org/D16231 llvm-svn: 267692
* [SROA] Don't falsely report that changes have occuredDavid Majnemer2016-04-261-6/+10
| | | | | | | | | We would report that the function changed despite creating no new allocas or performing any promotion. This fixes PR27316. llvm-svn: 267507
* Re-commit optimization bisect support (r267022) without new pass manager ↵Andrew Kaylor2016-04-221-1/+1
| | | | | | | | | | support. The original commit was reverted because of a buildbot problem with LazyCallGraph::SCC handling (not related to the OptBisect handling). Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267231
* Revert "Initial implementation of optimization bisect support."Vedant Kumar2016-04-221-5/+1
| | | | | | | | This reverts commit r267022, due to an ASan failure: http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/1549 llvm-svn: 267115
* Initial implementation of optimization bisect support.Andrew Kaylor2016-04-211-1/+5
| | | | | | | | | | | | This patch implements a optimization bisect feature, which will allow optimizations to be selectively disabled at compile time in order to track down test failures that are caused by incorrect optimizations. The bisection is enabled using a new command line option (-opt-bisect-limit). Individual passes that may be skipped call the OptBisect object (via an LLVMContext) to see if they should be skipped based on the bisect limit. A finer level of control (disabling individual transformations) can be managed through an addition OptBisect method, but this is not yet used. The skip checking in this implementation is based on (and replaces) the skipOptnoneFunction check. Where that check was being called, a new call has been inserted in its place which checks the bisect limit and the optnone attribute. A new function call has been added for module and SCC passes that behaves in a similar way. Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267022
* Don't IPO over functions that can be de-refinedSanjoy Das2016-04-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fixes PR26774. If you're aware of the issue, feel free to skip the "Motivation" section and jump directly to "This patch". Motivation: I define "refinement" as discarding behaviors from a program that the optimizer has license to discard. So transforming: ``` void f(unsigned x) { unsigned t = 5 / x; (void)t; } ``` to ``` void f(unsigned x) { } ``` is refinement, since the behavior went from "if x == 0 then undefined else nothing" to "nothing" (the optimizer has license to discard undefined behavior). Refinement is a fundamental aspect of many mid-level optimizations done by LLVM. For instance, transforming `x == (x + 1)` to `false` also involves refinement since the expression's value went from "if x is `undef` then { `true` or `false` } else { `false` }" to "`false`" (by definition, the optimizer has license to fold `undef` to any non-`undef` value). Unfortunately, refinement implies that the optimizer cannot assume that the implementation of a function it can see has all of the behavior an unoptimized or a differently optimized version of the same function can have. This is a problem for functions with comdat linkage, where a function can be replaced by an unoptimized or a differently optimized version of the same source level function. For instance, FunctionAttrs cannot assume a comdat function is actually `readnone` even if it does not have any loads or stores in it; since there may have been loads and stores in the "original function" that were refined out in the currently visible variant, and at the link step the linker may in fact choose an implementation with a load or a store. As an example, consider a function that does two atomic loads from the same memory location, and writes to memory only if the two values are not equal. The optimizer is allowed to refine this function by first CSE'ing the two loads, and the folding the comparision to always report that the two values are equal. Such a refined variant will look like it is `readonly`. However, the unoptimized version of the function can still write to memory (since the two loads //can// result in different values), and selecting the unoptimized version at link time will retroactively invalidate transforms we may have done under the assumption that the function does not write to memory. Note: this is not just a problem with atomics or with linking differently optimized object files. See PR26774 for more realistic examples that involved neither. This patch: This change introduces a new set of linkage types, predicated as `GlobalValue::mayBeDerefined` that returns true if the linkage type allows a function to be replaced by a differently optimized variant at link time. It then changes a set of IPO passes to bail out if they see such a function. Reviewers: chandlerc, hfinkel, dexonsmith, joker.eph, rnk Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D18634 llvm-svn: 265762
* [SROA] Fix typo in commentHal Finkel2016-03-281-1/+1
| | | | llvm-svn: 264573
* C++11 is required, remove some preprocessor checks for itHal Finkel2016-03-281-3/+3
| | | | | | | We require C++11 to build, so remove a few remaining preprocessor checks for '__cplusplus >= 201103L'. This should always be true. llvm-svn: 264572
* Remove PreserveNames template parameter from IRBuilderMehdi Amini2016-03-131-5/+4
| | | | | | | | This reapplies r263258, which was reverted in r263321 because of issues on Clang side. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263393
* Temporarily revert:Eric Christopher2016-03-121-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ae14bf6488e8441f0f6d74f00455555f6f3943ac Author: Mehdi Amini <mehdi.amini@apple.com> Date: Fri Mar 11 17:15:50 2016 +0000 Remove PreserveNames template parameter from IRBuilder Summary: Following r263086, we are now relying on a flag on the Context to discard Value names in release builds. Reviewers: chandlerc Subscribers: mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D18023 From: Mehdi Amini <mehdi.amini@apple.com> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263258 91177308-0d34-0410-b5e6-96231b3b80d8 until we can figure out what to do about clang and Release build testing. This reverts commit 263258. llvm-svn: 263321
* Remove PreserveNames template parameter from IRBuilderMehdi Amini2016-03-111-5/+4
| | | | | | | | | | | | | | | Summary: Following r263086, we are now relying on a flag on the Context to discard Value names in release builds. Reviewers: chandlerc Subscribers: mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D18023 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263258
* Do not specialize IRBuilder to strip names in SROAMehdi Amini2016-03-111-22/+10
| | | | | | | | | | | | | | | | | Summary: Following r263086, we are replacing this by a runtime check. More cleanup will follow on the IRBuilder itself, but I submitted this patch separately as SROA has a fancy "prefixInserter" class that needs extra-love. Reviewers: chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18022 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263256
* [PM] Make the AnalysisManager parameter to run methods a reference.Chandler Carruth2016-03-111-3/+3
| | | | | | | | | | | | This was originally a pointer to support pass managers which didn't use AnalysisManagers. However, that doesn't realistically come up much and the complexity of supporting it doesn't really make sense. In fact, *many* parts of the pass manager were just assuming the pointer was never null already. This at least makes it much more explicit and clear. llvm-svn: 263219
* [SROA] Fix PR25873, which Andrea Di Biagio analyzed the daylights outChandler Carruth2016-03-101-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of, and I misdiagnosed for months and months. Andrea has had a patch for this forever, but I just couldn't see how it was fixing the root cause of the problem. It didn't make sense to me, even though the patch was perfectly good and the analysis of the actual failure event was *fantastic*. Well, I came back to it today because the patch has sat for *far* too long and needs attention and decided I wouldn't let it go until I really understood what was going on. After quite some time in the debugger, I finally realized that in fact I had just missed an important case with my previous attempt to fix PR22093 in r225149. Not only do we need to handle loads that won't be split, but stores-of-loads that we won't split. We *do* actually have enough logic in the presplitting to form new slices for split stores.... *unless* we decided not to split them! I'm so sorry that it took me this long to come to the realization that this is the issue. It seems so obvious in hind sight (of course). Anyways, the fix becomes *much* smaller and more focused. The fact that we're left doing integer smashing is related to the FIXME in my original commit: fundamentally, we're not aggressive about pre-splitting for loads and stores to the same alloca. If we want to get aggressive about this, it'll need both what Andrea had put into the proposed fix, but also a *lot* more logic to essentially iteratively pre-split the alloca until we can't do any more. As I said in that commit log, its really unclear that this is the right call. Instead, the integer blending and letting targets lower this to narrower stores seems slightly better. But we definitely shouldn't really go down that path just to fix this bug. Again, tons of thanks are owed to Andrea and others at Sony for working on this bug. I really should have seen what was going on here and re-directed them sooner. =//// llvm-svn: 263121
* [SROA] Clean up some really weird code, no functionality changed.Chandler Carruth2016-03-101-3/+3
| | | | | | | | | | | We already have the instruction extracted into 'I', just cast that to a store the way we do for loads. Also, we don't enter the if unless SI is non-null, so don't test it again for null. I'm pretty sure the entire test there can be nuked, but this is just the trivial cleanup. llvm-svn: 263112
* Fix buildbot failure introduced by 258010. Remove local variables became unused.Artur Pilipenko2016-01-171-3/+0
| | | | llvm-svn: 258011
* Push isDereferenceableAndAlignedPointer down into isSafeToLoadUnconditionallyArtur Pilipenko2016-01-171-8/+3
| | | | | | | | Reviewed By: reames Differential Revision: http://reviews.llvm.org/D16226 llvm-svn: 258010
* Change isSafeToLoadUnconditionally arguments order. Separated from ↵Artur Pilipenko2016-01-151-3/+3
| | | | | | http://reviews.llvm.org/D10920. llvm-svn: 257894
* [SROA] Also insert a bit piece expression if only one piece is neededKeno Fischer2016-01-141-2/+5
| | | | | | | | | | | | | | Summary: If SROA creates only one piece (e.g. because the other is not needed), it still needs to create a bit_piece expression if that bit piece is smaller than the original size of the alloca. Reviewers: aprantl Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16187 llvm-svn: 257795
* getParent() ^ 3 == getModule() ; NFCISanjay Patel2015-12-141-2/+1
| | | | llvm-svn: 255511
* Revert "Change memcpy/memset/memmove to have dest and source alignments."Pete Cooper2015-11-191-18/+14
| | | | | | | | | | 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
OpenPOWER on IntegriCloud