summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/Loads.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [PM/AA] Extract the ModRef enums from the AliasAnalysis class inChandler Carruth2015-07-221-5/+2
| | | | | | | | | | | | | | | | | | | | | | | 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
* Take alignment into account in isSafeToLoadUnconditionallyArtur Pilipenko2015-06-251-6/+20
| | | | | | | | Reviewed By: hfinkel Differential Revision: http://reviews.llvm.org/D10475 llvm-svn: 240636
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-101-15/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make DataLayout Non-Optional in the ModuleMehdi Amini2015-03-041-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: DataLayout keeps the string used for its creation. As a side effect it is no longer needed in the Module. This is "almost" NFC, the string is no longer canonicalized, you can't rely on two "equals" DataLayout having the same string returned by getStringRepresentation(). Get rid of DataLayoutPass: the DataLayout is in the Module The DataLayout is "per-module", let's enforce this by not duplicating it more than necessary. One more step toward non-optionality of the DataLayout in the module. Make DataLayout Non-Optional in the Module Module->getDataLayout() will never returns nullptr anymore. Reviewers: echristo Subscribers: resistor, llvm-commits, jholewinski Differential Revision: http://reviews.llvm.org/D7992 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231270
* Remove getDataLayout() from Instruction/GlobalValue/BasicBlock/FunctionMehdi Amini2015-03-031-1/+2
| | | | | | | | | | | | | | | | | Summary: This does not conceptually belongs here. Instead provide a shortcut getModule() that provides access to the DataLayout. Reviewers: chandlerc, echristo Reviewed By: echristo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8027 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231147
* Revert r220349 to re-instate r220277 with a fix for PR21330 -- quiteChandler Carruth2014-11-251-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | clearly only exactly equal width ptrtoint and inttoptr casts are no-op casts, it says so right there in the langref. Make the code agree. Original log from r220277: Teach the load analysis to allow finding available values which require inttoptr or ptrtoint cast provided there is datalayout available. Eventually, the datalayout can just be required but in practice it will always be there today. To go with the ability to expose available values requiring a ptrtoint or inttoptr cast, helpers are added to perform one of these three casts. These smarts are necessary to finish canonicalizing loads and stores to the operational type requirements without regressing fundamental combines. I've added some test cases. These should actually improve as the load combining and store combining improves, but they may fundamentally be highlighting some missing combines for select in addition to exercising the specific added logic to load analysis. llvm-svn: 222739
* Revert "Teach the load analysis to allow finding available values which ↵Hans Wennborg2014-10-211-10/+4
| | | | | | | | require" (r220277) This seems to have caused PR21330. llvm-svn: 220349
* Teach the load analysis to allow finding available values which requireChandler Carruth2014-10-211-4/+10
| | | | | | | | | | | | | | | | | | | | inttoptr or ptrtoint cast provided there is datalayout available. Eventually, the datalayout can just be required but in practice it will always be there today. To go with the ability to expose available values requiring a ptrtoint or inttoptr cast, helpers are added to perform one of these three casts. These smarts are necessary to finish canonicalizing loads and stores to the operational type requirements without regressing fundamental combines. I've added some test cases. These should actually improve as the load combining and store combining improves, but they may fundamentally be highlighting some missing combines for select in addition to exercising the specific added logic to load analysis. llvm-svn: 220277
* Fix a miscompile introduced in r220178.Chandler Carruth2014-10-201-4/+5
| | | | | | | | | | | | | | | | | | The original code had an implicit assumption that if the test for allocas or globals was reached, the two pointers were not equal. With my changes to make the pointer analysis more powerful here, I also had to guard against circumstances where the results weren't useful. That in turn violated the assumption and gave rise to a circumstance in which we could have a store with both the queried pointer and stored pointer rooted at *the same* alloca. Clearly, we cannot ignore such a store. There are other things we might do in this code to better handle the case of both pointers ending up at the same alloca or global, but it seems best to at least make the test explicit in what it intends to check. I've added tests for both the alloca and global case here. llvm-svn: 220190
* Teach the load analysis driving core instcombine logic and other bits ofChandler Carruth2014-10-201-21/+43
| | | | | | | | | | | | | | | | | | | logic to look through pointer casts, making them trivially stronger in the face of loads and stores with intervening pointer casts. I've included a few test cases that demonstrate the kind of folding instcombine can do without pointer casts and then variations which obfuscate the logic through bitcasts. Without this patch, the variations all fail to optimize fully. This is more important now than it has been in the past as I've started moving the load canonicialization to more closely follow the value type requirements rather than the pointer type requirements and thus this needs to be prepared for more pointer casts. When I made the same change to stores several test cases regressed without logic along these lines so I wanted to systematically improve matters first. llvm-svn: 220178
* Fix a long-standing miscompile in the load analysis that was uncoveredChandler Carruth2014-10-191-11/+0
| | | | | | | | | | | | | | | | | | | by my refactoring of this code. The method isSafeToLoadUnconditionally assumes that the load will proceed with the preferred type alignment. Given that, it has to ensure that the alloca or global is at least that aligned. It has always done this historically when a datalayout is present, but has never checked it when the datalayout is absent. When I refactored the code in r220156, I exposed this path when datalayout was present and that turned the latent bug into a patent bug. This fixes the issue by just removing the special case which allows folding things without datalayout. This isn't worth the complexity of trying to tease apart when it is or isn't safe without actually knowing the preferred alignment. llvm-svn: 220161
* Switch how the datalayout availability test is handled in this code toChandler Carruth2014-10-191-7/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | make much more sense and in theory be more correct. If you trace the code alllll the way back to when it was first introduced, the comments make it slightly more clear what was going on here. At that time, the only way Base != V was if DL (then TD) was non-null. As a consequence, if DL *was* null, that meant we were loading directly from the alloca or global found above the test. After refactoring, this has become at least terribly subtle and potentially incorrect. There are many forms of pointer manipulation that can be traversed without DataLayout, and some of them would in fact change the size of object being loaded vs. allocated. Rather than this subtlety, I've hoisted the actual 'return true' bits into the code which actually found an alloca or global and based them on the loaded pointer being that alloca or global. This is both more clear and safer. I've also added comments about exactly why this set of predicates is used. I've also corrected a misleading comment about globals -- if overridden they may not just have a different size, they may be null and completely unsafe to load from! Hopefully this confuses the next reader a bit less. I don't have any test cases or anything, the patch is motivated strictly to improve the readability of the code. llvm-svn: 220156
* Rename 'TD' to 'DL' in this function as the argument is now a DataLayoutChandler Carruth2014-10-181-7/+7
| | | | | | argument. llvm-svn: 220151
* Fix the other comment to use modern doxygen style and be a bit moreChandler Carruth2014-10-181-4/+8
| | | | | | | direct. Notably, comment on the fact that the loaded type is significant in that it determines how wide of an access must be safe. llvm-svn: 220150
* More formatting cleanup brought to you by clang-format.Chandler Carruth2014-10-181-5/+8
| | | | llvm-svn: 220149
* Clean up doxygen syntax and reword comments to flow better, have a briefChandler Carruth2014-10-181-15/+20
| | | | | | section, and not have unfinished sentence fragments. llvm-svn: 220147
* Clean up the formatting and trailing whitespace of a routine beforeChandler Carruth2014-10-181-16/+19
| | | | | | editting it. llvm-svn: 220146
* AA metadata refactoring (introduce AAMDNodes)Hal Finkel2014-07-241-5/+5
| | | | | | | | | | | | | | | | | | | | In order to enable the preservation of noalias function parameter information after inlining, and the representation of block-level __restrict__ pointer information (etc.), additional kinds of aliasing metadata will be introduced. This metadata needs to be carried around in AliasAnalysis::Location objects (and MMOs at the SDAG level), and so we need to generalize the current scheme (which is hard-coded to just one TBAA MDNode*). This commit introduces only the necessary refactoring to allow for the introduction of other aliasing metadata types, but does not actually introduce any (that will come in a follow-up commit). What it does introduce is a new AAMDNodes structure to hold all of the aliasing metadata nodes associated with a particular memory-accessing instruction, and uses that structure instead of the raw MDNode* in AliasAnalysis::Location, etc. No functionality change intended. llvm-svn: 213859
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-151-5/+5
| | | | | | instead of comparing to nullptr. llvm-svn: 206243
* Change GetPointerBaseWithConstantOffset's DataLayout argument from aDan Gohman2013-01-311-2/+1
| | | | | | | reference to a pointer, so that it can handle the case where DataLayout is not available and behave conservatively. llvm-svn: 174024
* 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
* use ValueTracking's GetPointerBaseWithConstantOffset() function instead of a ↵Nuno Lopes2012-12-311-36/+8
| | | | | | local implementation llvm-svn: 171307
* Move TargetData to DataLayout.Micah Villmow2012-10-081-4/+4
| | | | llvm-svn: 165402
* enhance jump threading to preserve TBAA information when PRE'ing loads,Chris Lattner2012-03-131-3/+13
| | | | | | | fixing rdar://11039258, an issue that came up when inspecting clang's bootstrapped codegen. llvm-svn: 152635
* Add some comments here because the lack of a check for volatile/atomic here ↵Eli Friedman2011-08-151-0/+4
| | | | | | is a bit unusual. llvm-svn: 137662
* Convert TargetData::getIndexedOffset to use ArrayRef.Jay Foad2011-07-191-1/+1
| | | | llvm-svn: 135478
* land David Blaikie's patch to de-constify Type, with a few tweaks.Chris Lattner2011-07-181-3/+3
| | | | llvm-svn: 135375
* Test commit.Hans Wennborg2011-06-031-2/+2
| | | | llvm-svn: 132558
* Don't include Operator.h from InstrTypes.h.Jay Foad2011-04-111-0/+1
| | | | llvm-svn: 129271
* Move Value::getUnderlyingObject to be a standaloneDan Gohman2010-12-151-1/+1
| | | | | | | function so that it can live in Analysis instead of VMCore. llvm-svn: 121885
* Reapply r116831 and r116839, converting AliasAnalysis to useDan Gohman2010-10-191-1/+1
| | | | | | uint64_t, plus fixes for places I missed before. llvm-svn: 116875
* Move FindAvailableLoadedValue isSafeToLoadUnconditionally out ofDan Gohman2010-05-281-0/+235
lib/Transforms/Utils and into lib/Analysis so that Analysis passes can use them. llvm-svn: 104949
OpenPOWER on IntegriCloud