summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/MemoryBuiltins.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [MemoryBuiltins] Fix an issue with hasNoAliasAttrSanjoy Das2016-02-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: `hasNoAliasAttr` is buggy: it checks to see if the called function has a `noalias` attribute, which is incorrect since functions are not even allowed to have the `noalias` attribute. The comment on its only caller, `llvm::isNoAliasFn`, makes it pretty clear that the intention to do the `noalias` check on the return value, and not the callee. Unfortunately I couldn't find a way to test this upstream -- fixing this does not change the observable behavior of any of the passes that use this. This is not very surprising, since `noalias` does not tell anything about the contents of the allocated memory (so, e.g., you still cannot fold loads). I'll be happy to be proven wrong though. Reviewers: chandlerc, reames Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D17037 llvm-svn: 260298
* Update to use new name alignTo().Rui Ueyama2016-01-141-1/+1
| | | | llvm-svn: 257804
* [MemoryBuiltins] Remove isOperatorNewLike by consolidating non-null ↵Philip Reames2016-01-041-7/+0
| | | | | | | | | | | | inference handling This patch removes the isOperatorNewLike predicate since it was only being used to establish a non-null return value and we have attributes specifically for that purpose with generic handling. To keep approximate the same behaviour for existing frontends, I added the various operator new like (i.e. instances of operator new) to InferFunctionAttrs. It's not really clear to me why this isn't handled in Clang, but I didn't want to break existing code and any subtle assumptions it might have. Once this patch is in, I'm going to start separating the isAllocLike family of predicates. These appear to be being used for a mixture of things which should be more clearly separated and documented. Today, they're being used to indicate (at least) aliasing facts, CSE-ability, and default values from an allocation site. Differential Revision: http://reviews.llvm.org/D15820 llvm-svn: 256787
* [MemoryBuiltins] Delete dead code [NFC]Philip Reames2015-12-291-7/+0
| | | | llvm-svn: 256565
* [Analysis] Become aware of MSVC's new/delete functionsDavid Majnemer2015-12-031-2/+22
| | | | | | | | The compiler can take advantage of the allocation/deallocation function's properties. We knew how to do this for Itanium but had no support for MSVC-style functions. llvm-svn: 254656
* Specify explicit storage type for AllocType. NFC.George Burgess IV2015-11-171-1/+1
| | | | llvm-svn: 253366
* Use find_if to simplify control flow. NFC.Benjamin Kramer2015-10-241-10/+5
| | | | llvm-svn: 251200
* Analysis: Remove implicit ilist iterator conversionsDuncan P. N. Exon Smith2015-10-101-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove implicit ilist iterator conversions from LLVMAnalysis. I came across something really scary in `llvm::isKnownNotFullPoison()` which relied on `Instruction::getNextNode()` being completely broken (not surprising, but scary nevertheless). This function is documented (and coded to) return `nullptr` when it gets to the sentinel, but with an `ilist_half_node` as a sentinel, the sentinel check looks into some other memory and we don't recognize we've hit the end. Rooting out these scary cases is the reason I'm removing the implicit conversions before doing anything else with `ilist`; I'm not at all surprised that clients rely on badness. I found another scary case -- this time, not relying on badness, just bad (but I guess getting lucky so far) -- in `ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the insertion point, do some things, and then restore it. Previously, we let the iterator auto-convert to `Instruction*`, and then set it back using the `Instruction*` version: Instruction *PrevInsertPoint = Builder.GetInsertPoint(); /* Logic that may change insert point */ if (PrevInsertPoint) Builder.SetInsertPoint(PrevInsertPoint); The check for `PrevInsertPoint` doesn't protect correctly against bad accesses. If the insertion point has been set to the end of a basic block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns an iterator pointing at the list sentinel. The version of `SetInsertPoint()` that's getting called will then call `PrevInsertPoint->getParent()`, which explodes horribly. The only reason this hasn't blown up is that it's fairly unlikely the builder is adding to the end of the block; usually, we're adding instructions somewhere before the terminator. llvm-svn: 249925
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-101-25/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that the DataLayout is a mandatory part of the module, let's start cleaning the codebase. This patch is a first attempt at doing that. This patch is not exactly NFC as for instance some places were passing a nullptr instead of the DataLayout, possibly just because there was a default value on the DataLayout argument to many functions in the API. Even though it is not purely NFC, there is no change in the validation. I turned as many pointer to DataLayout to references, this helped figuring out all the places where a nullptr could come up. I had initially a local version of this patch broken into over 30 independant, commits but some later commit were cleaning the API and touching part of the code modified in the previous commits, so it seemed cleaner without the intermediate state. Test Plan: Reviewers: echristo Subscribers: llvm-commits From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231740
* DCE: isArrayMalloc() is not used neither in LLVM nor ClangMehdi Amini2015-03-091-17/+0
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231624
* [PM] Move TargetLibraryInfo into the Analysis library.Chandler Carruth2015-01-151-1/+1
| | | | | | | | | | | | | | | | While the term "Target" is in the name, it doesn't really have to do with the LLVM Target library -- this isn't an abstraction which LLVM targets generally need to implement or extend. It has much more to do with modeling the various runtime libraries on different OSes and with different runtime environments. The "target" in this sense is the more general sense of a target of cross compilation. This is in preparation for porting this analysis to the new pass manager. No functionality changed, and updates inbound for Clang and Polly. llvm-svn: 226078
* For PR21145: recognise a builtin call to a known deallocation function even ifRichard Smith2015-01-151-1/+1
| | | | | | | | it's defined in the current module. Clang generates this situation for the C++14 sized deallocation functions, because it generates a weak definition in case one isn't provided by the C++ runtime library. llvm-svn: 226069
* Update SetVector to rely on the underlying set's insert to return a ↵David Blaikie2014-11-191-2/+2
| | | | | | | | | | | | | pair<iterator, bool> This is to be consistent with StringSet and ultimately with the standard library's associative container insert function. This lead to updating SmallSet::insert to return pair<iterator, bool>, and then to update SmallPtrSet::insert to return pair<iterator, bool>, and then to update all the existing users of those functions... llvm-svn: 222334
* PR21145: Teach LLVM about C++14 sized deallocation functions.Richard Smith2014-10-031-1/+5
| | | | | | | | C++14 adds new builtin signatures for 'operator delete'. This change allows new/delete pairs to be removed in C++14 onwards, as they were in C++11 and before. llvm-svn: 219014
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-1/+2
| | | | | | | | | | definition below all the header #include lines, lib/Analysis/... edition. This one has a bit extra as there were *other* #define's before #include lines in addition to DEBUG_TYPE. I've sunk all of them as a block. llvm-svn: 206843
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-151-27/+27
| | | | | | instead of comparing to nullptr. llvm-svn: 206243
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
* Update optimization passes to handle inalloca argumentsReid Kleckner2014-01-281-1/+1
| | | | | | | | | | | | | | | Summary: I searched Transforms/ and Analysis/ for 'ByVal' and updated those call sites to check for inalloca if appropriate. I added tests for any change that would allow an optimization to fire on inalloca. Reviewers: nlewycky Differential Revision: http://llvm-reviews.chandlerc.com/D2449 llvm-svn: 200281
* Teach MemoryBuiltins about address spacesMatt Arsenault2013-12-141-5/+11
| | | | llvm-svn: 197292
* fix PR17635: false positive with packed structuresNuno Lopes2013-10-241-3/+5
| | | | | | LLVM optimizers may widen accesses to packed structures that overflow the structure itself, but should be in bounds up to the alignment of the object llvm-svn: 193317
* Rename DataLayout variables TD -> DLMatt Arsenault2013-10-031-26/+25
| | | | llvm-svn: 191927
* ObjectSizeOffsetEvaluator: Don't run into infinite recursion if we have a ↵Benjamin Kramer2013-09-291-5/+7
| | | | | | | | cyclic GEP. Those can occur in dead code. PR17402. llvm-svn: 191644
* MemoryBuiltins: Remove posix_memalign from the list and replace it with a TODO.Benjamin Kramer2013-09-241-1/+1
| | | | | | | This code isn't ready to deal with allocation functions where the return is not the allocated pointer. The checks below will reject posix_memalign anyways. llvm-svn: 191319
* MemoryBuiltins: Reinstate optimizing (uninitialized) loads from operator new.Benjamin Kramer2013-09-241-7/+7
| | | | llvm-svn: 191315
* MemoryBuiltins: Fix operator new bits.Benjamin Kramer2013-09-241-3/+3
| | | | | | We really don't want to optimize malloc return value checks away. llvm-svn: 191313
* Teach MemoryBuiltins and InstructionSimplify that operator new never returns ↵Benjamin Kramer2013-09-241-4/+12
| | | | | | | | | | | | NULL. This is safe per C++11 18.6.1.1p3: [operator new returns] a non-null pointer to suitably aligned storage (3.7.4), or else throw a bad_alloc exception. This requirement is binding on a replacement version of this function. Brings us a tiny bit closer to eliminating more vector push_backs. llvm-svn: 191310
* Treat nothrow forms of ::operator delete and ::operator delete[] asRichard Smith2013-07-211-4/+10
| | | | | | deallocation functions. llvm-svn: 186798
* Added support for the Builtin attribute.Michael Gottesman2013-06-271-1/+1
| | | | | | | | The Builtin attribute is an attribute that can be placed on function call site that signal that even though a function is declared as being a builtin, rdar://problem/13727199 llvm-svn: 185049
* Respect the 'nobuiltin' attribute when determining if a call is to a memory ↵Richard Smith2013-05-161-0/+3
| | | | | | builtin. llvm-svn: 181978
* Revert r176408 and r176407 to address PR15540.Nadav Rotem2013-04-091-49/+12
| | | | llvm-svn: 179111
* Revert 179071 because it is not the right way to support non standard ↵Nadav Rotem2013-04-091-0/+8
| | | | | | new/new[] operators. llvm-svn: 179084
* c++ new operators are not malloc-like functions because they do not return ↵Nadav Rotem2013-04-081-8/+0
| | | | | | | | uninitialized memory. Users may overide new-operators and implement any function that they like. llvm-svn: 179071
* Early exit from getAllocationData() and isFreeCall() for intrinsics.Michael Ilseman2013-03-081-1/+5
| | | | llvm-svn: 176722
* Remove trailing whitespaceMichael Ilseman2013-03-081-5/+5
| | | | llvm-svn: 176720
* Simplify code. No functionality change.Jakub Staszak2013-03-071-3/+3
| | | | llvm-svn: 176646
* Change NULL to 0.Jakub Staszak2013-03-071-8/+8
| | | | llvm-svn: 176642
* recommit r172363 & r171325 (reverted in r172756)Nuno Lopes2013-03-021-12/+29
| | | | | | | | This adds minimalistic support for PHI nodes to llvm.objectsize() evaluation fingers crossed so that it does break clang boostrap again.. llvm-svn: 176408
* add getUnderlyingObjectSize()Nuno Lopes2013-03-021-0/+20
| | | | | | | this is similar to getObjectSize(), but doesnt subtract the offset tweak the BasicAA code accordingly (per PR14988) llvm-svn: 176407
* Reverting r171325 & r172363. This was causing a mis-compile on the ↵Bill Wendling2013-01-171-29/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | self-hosted LTO build bots. Okay, here's how to reproduce the problem: 1) Build a Release (or Release+Asserts) version of clang in the normal way. 2) Using the clang & clang++ binaries from (1), build a Release (or Release+Asserts) version of the same sources, but this time enable LTO --- specify the `-flto' flag on the command line. 3) Run the ARC migrator tests: $ arcmt-test --args -triple x86_64-apple-darwin10 -fsyntax-only -x objective-c++ ./src/tools/clang/test/ARCMT/cxx-rewrite.mm You'll see that the output isn't correct (the whitespace is off). The mis-compile is in the function `RewriteBuffer::RemoveText' in the clang/lib/Rewrite/Core/Rewriter.cpp file. When that function and RewriteRope.cpp are compiled with LTO and the `arcmt-test' executable is regenerated, you'll see the error. When those files are not LTO'ed, then the output of the `arcmt-test' is fine. It is *really* hard to get a testcase out of this. I'll file a PR with what I have currently. --- Reverse-merging r172363 into '.': U include/llvm/Analysis/MemoryBuiltins.h U lib/Analysis/MemoryBuiltins.cpp --- Reverse-merging r171325 into '.': U test/Transforms/InstCombine/objsize.ll G include/llvm/Analysis/MemoryBuiltins.h G lib/Analysis/MemoryBuiltins.cpp llvm-svn: 172756
* fix compile-time regression report by Joerg Sonnenberger:Nuno Lopes2013-01-131-9/+11
| | | | | | cache result of Size/OffsetVisitor to speedup analysis of PHI nodes llvm-svn: 172363
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-6/+6
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* recommit r171298 (add support for PHI nodes to ObjectSizeOffsetVisitor). ↵Nuno Lopes2012-12-311-11/+26
| | | | | | Hopefully with bugs corrected now. llvm-svn: 171325
* Revert "add support for PHI nodes to ObjectSizeOffsetVisitor"Benjamin Kramer2012-12-311-14/+3
| | | | | | This reverts r171298. Breaks clang selfhost. llvm-svn: 171318
* revert r171306, since we cannot compare APInts with different bitwidthsNuno Lopes2012-12-311-1/+1
| | | | llvm-svn: 171308
* minor code simplificationNuno Lopes2012-12-311-1/+1
| | | | llvm-svn: 171306
* add support for GlobalAlias to ObjectSizeOffsetVisitorNuno Lopes2012-12-311-0/+9
| | | | llvm-svn: 171303
* add support for PHI nodes to ObjectSizeOffsetVisitorNuno Lopes2012-12-311-3/+14
| | | | llvm-svn: 171298
* convert a bunch of callers from DataLayout::getIndexedOffset() to ↵Nuno Lopes2012-12-301-3/+2
| | | | | | | | | GEP::accumulateConstantOffset(). The later API is nicer than the former, and is correct regarding wrap-around offsets (if anyone cares). There are a few more places left with duplicated code, which I'll remove soon. llvm-svn: 171259
* Rename the 'Attributes' class to 'Attribute'. It's going to represent a ↵Bill Wendling2012-12-191-1/+1
| | | | | | single attribute in the future. llvm-svn: 170502
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-4/+4
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
OpenPOWER on IntegriCloud