summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/BasicAliasAnalysis.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Merging r339636:Reid Kleckner2018-08-141-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------------------ r339636 | rnk | 2018-08-13 18:24:35 -0700 (Mon, 13 Aug 2018) | 17 lines [BasicAA] Don't assume tail calls with byval don't alias allocas Summary: Calls marked 'tail' cannot read or write allocas from the current frame because the current frame might be destroyed by the time they run. However, a tail call may use an alloca with byval. Calling with byval copies the contents of the alloca into argument registers or stack slots, so there is no lifetime issue. Tail calls never modify allocas, so we can return just ModRefInfo::Ref. Fixes PR38466, a longstanding bug. Reviewers: hfinkel, nlewycky, gbiv, george.burgess.iv Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D50679 ------------------------------------------------------------------------ llvm-svn: 339698
* [BasicAA] Use PhiValuesAnalysis if available when handling phi aliasJohn Brawn2018-07-301-25/+67
| | | | | | | | | | | | | | | | By using PhiValuesAnalysis we can get all the values reachable from a phi, so we can be more precise instead of giving up when a phi has phi operands. We can't make BaseicAA directly use PhiValuesAnalysis though, as the user of BasicAA may modify the function in ways that PhiValuesAnalysis can't cope with. For this optional usage to work correctly BasicAAWrapperPass now needs to be not marked as CFG-only (i.e. it is now invalidated even when CFG is preserved) due to how the legacy pass manager handles dependent passes being invalidated, namely the depending pass still has a pointer to the now-dead dependent pass. Differential Revision: https://reviews.llvm.org/D44564 llvm-svn: 338242
* llvm: Add support for "-fno-delete-null-pointer-checks"Manoj Gupta2018-07-091-15/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Support for this option is needed for building Linux kernel. This is a very frequently requested feature by kernel developers. More details : https://lkml.org/lkml/2018/4/4/601 GCC option description for -fdelete-null-pointer-checks: This Assume that programs cannot safely dereference null pointers, and that no code or data element resides at address zero. -fno-delete-null-pointer-checks is the inverse of this implying that null pointer dereferencing is not undefined. This feature is implemented in LLVM IR in this CL as the function attribute "null-pointer-is-valid"="true" in IR (Under review at D47894). The CL updates several passes that assumed null pointer dereferencing is undefined to not optimize when the "null-pointer-is-valid"="true" attribute is present. Reviewers: t.p.northover, efriedma, jyknight, chandlerc, rnk, srhines, void, george.burgess.iv Reviewed By: efriedma, george.burgess.iv Subscribers: eraman, haicheng, george.burgess.iv, drinkcat, theraven, reames, sanjoy, xbolva00, llvm-commits Differential Revision: https://reviews.llvm.org/D47895 llvm-svn: 336613
* Implement strip.invariant.groupPiotr Padlewski2018-07-021-7/+9
| | | | | | | | | | | | | | | | Summary: This patch introduce new intrinsic - strip.invariant.group that was described in the RFC: Devirtualization v2 Reviewers: rsmith, hfinkel, nlopes, sanjoy, amharc, kuhar Subscribers: arsenm, nhaehnle, JDevlieghere, hiraditya, xbolva00, llvm-commits Differential Revision: https://reviews.llvm.org/D47103 Co-authored-by: Krzysztof Pszeniczny <krzysztof.pszeniczny@gmail.com> llvm-svn: 336073
* [BasicAA] Teach the analysis about atomic memcpyDaniel Neilson2018-05-291-1/+1
| | | | | | | | Summary: A simple change to derive mod/ref info from the atomic memcpy intrinsic in the same way as from the regular memcpy intrinsic. llvm-svn: 333454
* Replace AA's uses of uint64_t with LocationSize; NFC.George Burgess IV2018-05-251-17/+19
| | | | | | | | | | | | | | | | The uint64_ts that we pass around AA to represent MemoryLocation sizes are logically an Optional<uint64_t>. In D44748, we want to add an extra 'imprecise' bit to this Optional<uint64_t> to represent whether a given MemoryLocation size is an upper-bound or an exact size. For more context on why, please see D44748. That patch is quite large, but reviewers seem to be OK with the approach. In D45581 (my first attempt to split 'noise' out of D44748), reames asked that I land a precursor that is solely replacing uint64_t with LocationSize, which starts out as `using LocationSize = uint64_t;`. He also gave me the OK to submit this rename without further review. llvm-svn: 333314
* Fix aliasing of launder.invariant.groupPiotr Padlewski2018-05-231-12/+12
| | | | | | | | | | | | | | | | | | | Summary: Patch for capture tracking broke bootstrap of clang with -fstict-vtable-pointers which resulted in debbugging nightmare. It was fixed https://reviews.llvm.org/D46900 but as it turned out, there were other parts like inliner (computing of noalias metadata) that I found after bootstraping with enabled assertions. Reviewers: hfinkel, rsmith, chandlerc, amharc, kuhar Subscribers: JDevlieghere, eraman, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D47088 llvm-svn: 333070
* [BasicAA] Fix handling of invariant group laundersKrzysztof Pszeniczny2018-05-161-1/+12
| | | | | | | | | | | | | | | | | Summary: A recent patch ([[ https://reviews.llvm.org/rL331587 | rL331587 ]]) to Capture Tracking taught it that the `launder_invariant_group` intrinsic captures its argument only by returning it. Unfortunately, BasicAA still considered every call instruction as a possible escape source and hence concluded that the result of a `launder_invariant_group` call cannot alias any local non-escaping value. This led to [[ https://bugs.llvm.org/show_bug.cgi?id=37458 | bug 37458 ]]. This patch updates the relevant check for escape sources in BasicAA. Reviewers: Prazek, kuhar, rsmith, hfinkel, sanjoy, xbolva00 Reviewed By: hfinkel, xbolva00 Subscribers: JDevlieghere, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D46900 llvm-svn: 332466
* Rename invariant.group.barrier to launder.invariant.groupPiotr Padlewski2018-05-031-6/+6
| | | | | | | | | | | | | | Summary: This is one of the initial commit of "RFC: Devirtualization v2" proposal: https://docs.google.com/document/d/16GVtCpzK8sIHNc2qZz6RN8amICNBtvjWUod2SujZVEo/edit?usp=sharing Reviewers: rsmith, amharc, kuhar, sanjoy Subscribers: arsenm, nhaehnle, javed.absar, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D45111 llvm-svn: 331448
* [BasicAA] Return MayAlias for the pointer plus variable offset toShiva Chen2018-04-161-6/+6
| | | | | | | | structure object member Differential Revision: https://reviews.llvm.org/D45510 llvm-svn: 330106
* [ModRefInfo] Return NoModRef for Must and NoModRef.Alina Sbirlea2018-01-191-1/+4
| | | | | | | | | | | | | | Summary: In ModRefInfo "Must" was introduced to track presence of MustAlias, but we still want to return NoModRef when there is neither Mod or Ref, even when MustAlias is found. Patch has small fixes to ensure this happens. Minor cleanup to remove nesting for 2 if statements when calling getModRefInfo for 2 ImmutableCallSites. Reviewers: sanjoy Subscribers: jlebar, llvm-commits Differential Revision: https://reviews.llvm.org/D42209 llvm-svn: 322932
* [BasicAA] Stop crashing when dealing with pointers > 64 bits.Davide Italiano2018-01-151-0/+7
| | | | | | | | | | | | | | | An alternative (and probably better) fix would be that of making `Scale` an APInt, and there's a patch floating around to do this. As we're still discussing it, at least stop crashing in the meanwhile (added bonus, we now have a regression test for this situation). Fixes PR35843. Thanks to Eli for suggesting the fix and Simon for reporting and reducing the bug. llvm-svn: 322467
* [BasicAA] Fix linearization of shifts beyond the bitwidth.Davide Italiano2018-01-051-0/+13
| | | | | | | Thanks to Simon Pilgrim for the reduced testcase. Fixes PR35821. llvm-svn: 321873
* [ModRefInfo] Add must alias info to ModRefInfo.Alina Sbirlea2017-12-211-2/+11
| | | | | | | | | | | | | | | | | | | | | | Summary: Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases. Shift existing Mod/Ref/ModRef values to include an additional most significant bit. Update wrappers that modify ModRefInfo values to reflect the change. Notes: * ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it. * Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA). * GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost. * There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location. Reviewers: dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38862 llvm-svn: 321309
* [ModRefInfo] Make enum ModRefInfo an enum class [NFC].Alina Sbirlea2017-12-071-18/+20
| | | | | | | | | | | | | | | Summary: Make enum ModRefInfo an enum class. Changes to ModRefInfo values should be done using inline wrappers. This should prevent future bit-wise opearations from being added, which can be more error-prone. Reviewers: sanjoy, dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40933 llvm-svn: 320107
* [ModRefInfo] Replace remaining bit-wise operations with wrappers.Alina Sbirlea2017-12-071-1/+1
| | | | llvm-svn: 319993
* [ModRefInfo] Use createModRefInfo wrapper to create a ModRefInfo from ↵Alina Sbirlea2017-12-061-4/+4
| | | | | | FunctionModRefBehavior. llvm-svn: 319941
* Modify ModRefInfo values using static inline method abstractions [NFC].Alina Sbirlea2017-12-051-7/+9
| | | | | | | | | | | | | | | | | Summary: The aim is to make ModRefInfo checks and changes more intuitive and less error prone using inline methods that abstract the bit operations. Ideally ModRefInfo would become an enum class, but that change will require a wider set of changes into FunctionModRefBehavior. Reviewers: sanjoy, george.burgess.iv, dberlin, hfinkel Subscribers: nlopes, llvm-commits Differential Revision: https://reviews.llvm.org/D40749 llvm-svn: 319821
* revert r317812 [BasicAA] fix build break by converting the previously ↵Nuno Lopes2017-11-091-2/+1
| | | | | | | | | introduced assert into an if stmt The code has a bug, but some tests regress. I'll discuss this further on the mailing list. llvm-svn: 317815
* [BasicAA] fix build break by converting the previously introduced assert ↵Nuno Lopes2017-11-091-2/+2
| | | | | | | | into an if stmt Apparently V1Size == -1 doest imply V2Size == -1, which is a bit surprising to me. llvm-svn: 317812
* [BasicAA] add assertion for corner case in aliasGEP()Nuno Lopes2017-11-091-0/+1
| | | | llvm-svn: 317803
* BasicAA: fix bug where we would return partialalias instead of noaliasNuno Lopes2017-11-081-3/+3
| | | | | | | | | | | | | | | My fix is conservative and will make us return may-alias instead. The test case is: check(gep(x, 0), n, gep(x, n), -1) with n == sizeof(x) Here, the first value accesses the whole object, but the second access doesn't access anything. The semantics of -1 is read until the end of the object, which in this case means read nothing. No test case, since isn't trivial to exploit this one, but I've proved it correct. llvm-svn: 317680
* Allow inaccessiblememonly and inaccessiblemem_or_argmemonly to be overwriten ↵Yichao Yu2017-11-021-0/+4
| | | | | | | | | | | | | | | | | | | on call site with operand bundle Summary: Similar to argmemonly, readonly and readnone. Fix PR35128 Reviewers: andrew.w.kaylor, chandlerc, hfinkel Reviewed By: hfinkel Subscribers: hfinkel, llvm-commits Differential Revision: https://reviews.llvm.org/D39434 llvm-svn: 317201
* Fix PR33878: BasicAA incorrectly assumes different address spaces don't aliasNuno Lopes2017-09-061-5/+0
| | | | | | | | | Remove code that assumed that a nullptr of address space != 0 couldnt alias with a non-null pointer. This is incorrect, since nothing can be concluded about a null pointer in an address space != 0. This code was written before address spaces were introduced Differential Revision: https://reviews.llvm.org/D37518 llvm-svn: 312648
* [Analysis] Fix some Clang-tidy modernize-use-using and Include What You Use ↵Eugene Zelenko2017-08-111-7/+25
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 310766
* BasicAA: assert on another case where aliasGEP shouldn't get a PartialAlias ↵Nuno Lopes2017-08-081-1/+3
| | | | | | response llvm-svn: 310420
* BasicAA: aliasGEP shouldn't get a PartialAlias response hereNuno Lopes2017-08-081-1/+3
| | | | | | add an assert() to ensure that's the case (as I'm not convinced it won't happen) llvm-svn: 310373
* Whitespace.NAKAMURA Takumi2017-07-111-1/+1
| | | | llvm-svn: 307614
* Revert r307581, "Avoid doing conservative phi checks in ↵NAKAMURA Takumi2017-07-111-11/+7
| | | | | | | | aliasSameBasePointerGEPs() if no phis have been visited yet." It broke stage2 tests in selfhosting. llvm-svn: 307613
* Avoid doing conservative phi checks in aliasSameBasePointerGEPs() if no phis ↵Farhana Aleen2017-07-101-7/+11
| | | | | | | | | | | | have been visited yet. Reviewers: Daniel Berlin Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34478 llvm-svn: 307581
* [BasicAA] Add type check and Value equality check around code added in r305481.Craig Topper2017-06-221-5/+8
| | | | | | | | This matches the checks done at the beginning of isKnownNonEqual that this code is partially emulating. Without this we can get assertion failures due to the bit widths of the KnownBits not matching. llvm-svn: 306044
* [BasicAA] Use MayAlias instead of PartialAlias for fallback.Michael Kruse2017-06-211-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using various methods, BasicAA tries to determine whether two GetElementPtr memory locations alias when its base pointers are known to be equal. When none of its heuristics are applicable, it falls back to PartialAlias to, according to a comment, protect TBAA making a wrong decision in case of unions and malloc. PartialAlias is not correct, because a PartialAlias result implies that some, but not all, bytes overlap which is not necessarily the case here. AAResults returns the first analysis result that is not MayAlias. BasicAA is always the first alias analysis. When it returns PartialAlias, no other analysis is queried to give a more exact result (which was the intention of returning PartialAlias instead of MayAlias). For instance, ScopedAA could return a more accurate result. The PartialAlias hack was introduced in r131781 (and re-applied in r132632 after some reverts) to fix llvm.org/PR9971 where TBAA returns a wrong NoAlias result due to a union. A test case for the malloc case mentioned in the comment was not provided and I don't think it is affected since it returns an omnipotent char anyway. Since r303851 (https://reviews.llvm.org/D33328) clang does emit specific TBAA for unions anymore (but "omnipotent char" instead). Hence, the PartialAlias workaround is not required anymore. This patch passes the test-suite and check-llvm/check-clang of a self-hoisted build on x64. Reviewed By: hfinkel Differential Revision: https://reviews.llvm.org/D34318 llvm-svn: 305938
* [BasicAA] Don't call isKnownNonEqual if we might be have gone through a PHINode.Craig Topper2017-06-151-4/+18
| | | | | | | | | | | | This is a fix for the test case in PR32314. Basic Alias Analysis can ask if two nodes are known non-equal after looking through a phi node to find a GEP. isAddOfNonZero saw an add of a constant from the same phi and said that its output couldn't be equal. But Basic Alias Analysis was really asking about the value from the previous loop iteration. This patch at least makes that case not happen anymore, I'm not sure if there were still other ways this can fail. As was discussed in the bug, it looks like fixing BasicAA would be difficult so this patch seemed like a possible workaround Differential Revision: https://reviews.llvm.org/D33136 llvm-svn: 305481
* BasicAA: Uninserted instructions have no parent, and notDifferentParent ↵Daniel Berlin2017-05-191-1/+4
| | | | | | explicitly allows for this case, but getParent crashes when handed one. llvm-svn: 303442
* [ValueTracking] Replace all uses of ComputeSignBit with computeKnownBits.Craig Topper2017-05-151-2/+4
| | | | | | | | This patch finishes off the conversion of ComputeSignBit to computeKnownBits. Differential Revision: https://reviews.llvm.org/D33166 llvm-svn: 303035
* [BasicAA] Alphabetize includes. NFCCraig Topper2017-05-141-1/+1
| | | | llvm-svn: 303002
* [ValueTracking] Remove const_casts on several calls to computeKnownBits and ↵Craig Topper2017-05-131-2/+1
| | | | | | ComputeSignBit. NFC llvm-svn: 302991
* Handle invariant.group.barrier in BasicAAPiotr Padlewski2017-04-241-6/+6
| | | | | | | | | | | | | | | | | | | | | Summary: llvm.invariant.group.barrier returns pointer that mustalias pointer it takes. It can't be marked with `returned` attribute, because it would be remove easily. The other reason is that only Alias Analysis can know about this, because if any other pass would know it, then the result would be replaced with it's argument, which would be invalid. We can think about returned pointer as something that mustalias, but it doesn't have to be bitwise the same as the argument. Reviewers: dberlin, chandlerc, hfinkel, sanjoy Subscribers: reames, nlewycky, rsmith, anna, amharc Differential Revision: https://reviews.llvm.org/D31585 llvm-svn: 301227
* Add a getPointerOperandType() helper to LoadInst and StoreInst; NFCSanjoy Das2017-04-181-6/+4
| | | | | | I will use this in a later change. llvm-svn: 300613
* [MemoryBuiltins] Add isMallocOrCallocLikeFn so BasicAA can check for both at ↵Craig Topper2017-04-181-1/+1
| | | | | | | | | | | | | | the same time BasicAA wants to know if a function is either a malloc or calloc like function. Currently we have to check both separately. This means both calls check if its an intrinsic, query TLI, check the nobuiltin attribute, scan the AllocationFnData, etc. This patch adds a isMallocOrCallocLikeFn so we can go through all of the checks once per call. This also changes the one other location I saw that called both together. Differential Revision: https://reviews.llvm.org/D32188 llvm-svn: 300608
* [IR] Make paramHasAttr to use arg indices instead of attr indicesReid Kleckner2017-04-141-3/+3
| | | | | | | | | This avoids the confusing 'CS.paramHasAttr(ArgNo + 1, Foo)' pattern. Previously we were testing return value attributes with index 0, so I introduced hasReturnAttr() for that use case. llvm-svn: 300367
* Let llvm.objectsize be conservative with null pointersGeorge Burgess IV2017-03-211-1/+3
| | | | | | | | | | | This adds a parameter to @llvm.objectsize that makes it return conservative values if it's given null. This fixes PR23277. Differential Revision: https://reviews.llvm.org/D28494 llvm-svn: 298430
* [BasicAA] Take attributes into account when requesting modref info for a ↵Igor Laevsky2017-03-011-9/+31
| | | | | | | | call site Differential Revision: https://reviews.llvm.org/D29989 llvm-svn: 296617
* Fix BasicAA incorrect assumption on GEPMehdi Amini2017-01-271-5/+5
| | | | | | | | | | | | | | This is fixing pr31761: BasicAA is deducing NoAlias on the result of the GEP if the base pointer is itself NoAlias. This is possible only if the NoAlias on the base pointer is deduced with a non-sized query: this should guarantee that the pointers are belonging to different memory allocation and that the GEP can't legally jump from one to another. Differential Revision: https://reviews.llvm.org/D29216 llvm-svn: 293293
* [Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)David L. Jones2017-01-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The LibFunc::Func enum holds enumerators named for libc functions. Unfortunately, there are real situations, including libc implementations, where function names are actually macros (musl uses "#define fopen64 fopen", for example; any other transitively visible macro would have similar effects). Strictly speaking, a conforming C++ Standard Library should provide any such macros as functions instead (via <cstdio>). However, there are some "library" functions which are not part of the standard, and thus not subject to this rule (fopen64, for example). So, in order to be both portable and consistent, the enum should not use the bare function names. The old enum naming used a namespace LibFunc and an enum Func, with bare enumerators. This patch changes LibFunc to be an enum with enumerators prefixed with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override macros.) There are additional changes required in clang. Reviewers: rsmith Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits Differential Revision: https://reviews.llvm.org/D28476 llvm-svn: 292848
* [PM] Remove a pointless optimization.Chandler Carruth2016-12-271-3/+0
| | | | | | | | There is no need to do this within an analysis. That method shouldn't even be reached if this predicate holds as the actual useful optimization is in the analysis manager itself. llvm-svn: 290614
* [PM] Teach BasicAA how to invalidate its result object.Chandler Carruth2016-12-271-0/+18
| | | | | | | | | | | | | | | This requires custom handling because BasicAA caches handles to other analyses and so it needs to trigger indirect invalidation. This fixes one of the common crashes when using the new PM in real pipelines. I've also tweaked a regression test to check that we are at least handling the most immediate case. I'm going to work at re-structuring this test some to both scale better (rather than all being in one file) and check more invalidation paths in a follow-up commit, but I wanted to get the basic bug fix in place. llvm-svn: 290603
* [AliasAnalysis] Teach BasicAA about memcpy.Bryant Wong2016-12-251-0/+25
| | | | | | Differential Revision: https://reviews.llvm.org/D27034 llvm-svn: 290526
* Revert @llvm.assume with operator bundles (r289755-r289757)Daniel Jasper2016-12-191-21/+28
| | | | | | | This creates non-linear behavior in the inliner (see more details in r289755's commit thread). llvm-svn: 290086
* Fix argument attribute queries with bundle operandsHal Finkel2016-12-151-1/+2
| | | | | | | When iterating over data operands in AA, don't make argument-attribute-specific queries on bundle operands. Trying to fix self hosting... llvm-svn: 289765
OpenPOWER on IntegriCloud