summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis
Commit message (Collapse)AuthorAgeFilesLines
* [PM/AA] Clean up and homogenize comments throughout basic-aa.Chandler Carruth2015-08-061-52/+59
| | | | llvm-svn: 244200
* [PM/AA] Run clang-format over all of basic-aa before making moreChandler Carruth2015-08-061-59/+60
| | | | | | substantive edits. llvm-svn: 244198
* [PM/AA] Hoist the interface for BasicAA into a header file.Chandler Carruth2015-08-061-192/+10
| | | | | | | | | | | | | This is the first mechanical step in preparation for making this and all the other alias analysis passes available to the new pass manager. I'm factoring out all the totally boring changes I can so I'm moving code around here with no other changes. I've even minimized the formatting churn. I'll reformat and freshen comments on the interface now that its located in the right place so that the substantive changes don't triger this. llvm-svn: 244197
* [PM/AA] Simplify the AliasAnalysis interface by removing a wrapperChandler Carruth2015-08-065-66/+63
| | | | | | | | | | | | | | | | around a DataLayout interface in favor of directly querying DataLayout. This wrapper specifically helped handle the case where this no DataLayout, but LLVM now requires it simplifynig all of this. I've updated callers to directly query DataLayout. This in turn exposed a bunch of places where we should have DataLayout readily available but don't which I've fixed. This then in turn exposed that we were passing DataLayout around in a bunch of arguments rather than making it readily available so I've also fixed that. No functionality changed. llvm-svn: 244189
* Add a stat to show how often the limit to decompose GEPs in BasicAA is reached.Wei Mi2015-08-051-0/+11
| | | | | | Differential Revision: http://reviews.llvm.org/D9689 llvm-svn: 244174
* [PM] Remove a failed attempt to port the CallGraph analysis to the newChandler Carruth2015-08-051-6/+0
| | | | | | | | | | | | | pass manager. This never worked, and won't ever work. It was actually why I ended up building the LazyCallGraph set of code which is more more effectively wired up to the new pass manager. This accidentally got committed when I was trying to land a cleanup of the code organization in the other parts of this file. =[ My bad, but fortunately Dave was keen eyed enough to spot that this code couldn't possibly work. =] llvm-svn: 244127
* -Wdeprecated cleanup: Make CallGraph movable by default by using unique_ptr ↵David Blaikie2015-08-051-13/+11
| | | | | | | | | | members rather than raw pointers. The only place that tries to return a CallGraph by value (CallGraphAnalysis::run) doesn't seem to be used right now, but it's a reasonable bit of cleanup anyway. llvm-svn: 244122
* [TTI] Make the cost APIs in TargetTransformInfo consistently use 'int'Chandler Carruth2015-08-051-70/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | rather than 'unsigned' for their costs. For something like costs in particular there is a natural "negative" value, that of savings or saved cost. As a consequence, there is a lot of code that subtracts or creates negative values based on cost, all of which is prone to awkwardness or bugs when dealing with an unsigned type. Similarly, we *never* want these values to wrap, as that would cause Very Bad code generation (likely percieved as an infinite loop as we try to emit over 2^32 instructions or some such insanity). All around 'int' seems a much better fit for these basic metrics. I've added asserts to ensure that at least the TTI interface never returns negative numbers here. If we ever have a use case for negative numbers, we can remove this, but this way a bug where someone used '-1' to produce a 'very large' cost will be caught by the assert. This passes all tests, and is also UBSan clean. No functional change intended. Differential Revision: http://reviews.llvm.org/D11741 llvm-svn: 244080
* [GMR] Teach the conservative path of GMR to catch even more easy cases.Chandler Carruth2015-08-051-41/+111
| | | | | | | | | | | | | | In PR24288 it was pointed out that the easy case of a non-escaping global and something that *obviously* required an escape sometimes is hidden behind PHIs (or selects in theory). Because we have this binary test, we can easily just check that all possible input values satisfy the requirement. This is done with a (very small) recursion through PHIs and selects. With this, the specific example from the PR is correctly folded by GVN. Differential Revision: http://reviews.llvm.org/D11707 llvm-svn: 244078
* [AA] Use CallSite cast idiom. No functionality change.Benjamin Kramer2015-08-051-3/+2
| | | | llvm-svn: 244045
* [LAA] Remove unused pointer partition argument from addRuntimeCheck, NFCAdam Nemet2015-08-041-2/+2
| | | | | | | This variant of addRuntimeCheck is only used now from the LoopVectorizer which does not use this parameter. llvm-svn: 243955
* [LAA] Remove unused needsAnyChecking(), NFCAdam Nemet2015-08-031-11/+0
| | | | llvm-svn: 243921
* -Wdeprecated-clean: Fix cases of violating the rule of 5 in ways that are ↵David Blaikie2015-08-032-4/+2
| | | | | | | | | | | | | | | | | | | | | | deprecated in C++11 Various value handles needed to be copy constructible and copy assignable (mostly for their use in DenseMap). But to avoid an API that might allow accidental slicing, make these members protected in the base class and make derived classes final (the special members become implicitly public there - but disallowing further derived classes that might be sliced to the intermediate type). Might be worth having a warning a bit like -Wnon-virtual-dtor that catches public move/copy assign/ctors in classes with virtual functions. (suppressable in the same way - by making them protected in the base, and making the derived classes final) Could be fancier and only diagnose them when they're actually called, potentially. Also allow a few default implementations where custom implementations (especially with non-standard return types) were implemented. llvm-svn: 243909
* De-constify pointers to Type since they can't be modified. NFCCraig Topper2015-08-012-3/+3
| | | | | | This was already done in most places a while ago. This just fixes the ones that crept in over time. llvm-svn: 243842
* -Wdeprecated-clean: Fix cases of violating the rule of 5 in ways that are ↵David Blaikie2015-07-311-4/+3
| | | | | | deprecated in C++11 llvm-svn: 243788
* New EH representation for MSVC compatibilityDavid Majnemer2015-07-313-3/+23
| | | | | | | | | | This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
* [CaptureTracker] Provide an ordered basic block to PointerMayBeCapturedBeforeBruno Cardoso Lopes2015-07-315-72/+123
| | | | | | | | | | | | | | | | | | This patch is a follow up from r240560 and is a step further into mitigating the compile time performance issues in CaptureTracker. By providing the CaptureTracker with a "cached ordered basic block" instead of computing it every time, MemDepAnalysis can use this cache throughout its calls to AA->callCapturesBefore, avoiding to recompute it for every scanned instruction. In the same testcase used in r240560, compile time is reduced from 2min to 30s. This also fixes PR22348. rdar://problem/19230319 Differential Revision: http://reviews.llvm.org/D11364 llvm-svn: 243750
* Rename hasCompatibleFunctionAttributes->areInlineCompatible basedEric Christopher2015-07-292-4/+4
| | | | | | | on suggestions. Currently the function is only used for inline purposes and this is more descriptive for the use. llvm-svn: 243578
* [SCEV] Apply NSW and NUW flags via poison value analysisJingyue Wu2015-07-282-25/+268
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Make Scalar Evolution able to propagate NSW and NUW flags from instructions to SCEVs in some cases. This is based on reasoning about when poison from instructions with these flags would trigger undefined behavior. This gives a 13% speed-up on some Eigen3-based Google-internal microbenchmarks for NVPTX. There does not seem to be clear agreement about when poison should be considered to propagate through instructions. In this analysis, poison propagates only in cases where that should be uncontroversial. This change makes LSR able to create induction variables for expressions like &ptr[i + offset] for loops like this: for (int i = 0; i < limit; ++i) { sum += ptr[i + offset]; } Here ptr is a 64 bit pointer and offset is a 32 bit integer. For NVPTX, LSR currently creates an induction variable for i + offset instead, which is not as fast. Improving this situation is what brings the 13% speed-up on some Eigen3-based Google-internal microbenchmarks for NVPTX. There are more details in this discussion on llvmdev. June: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-June/thread.html#87234 July: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-July/thread.html#87392 Patch by Bjarke Roune Reviewers: eliben, atrick, sanjoy Subscribers: majnemer, hfinkel, jingyue, meheff, llvm-commits Differential Revision: http://reviews.llvm.org/D11212 llvm-svn: 243460
* [LVI] Cleanup whitespaces. NFCBruno Cardoso Lopes2015-07-281-61/+61
| | | | llvm-svn: 243430
* [LAA] Add clarifying comments for the checking pointer grouping algorithm. NFCSilviu Baranga2015-07-281-1/+24
| | | | llvm-svn: 243416
* [GMR] Teach GlobalsModRef to distinguish an important and safe case ofChandler Carruth2015-07-281-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | no-alias with non-addr-taken globals: they cannot alias a captured pointer. If the non-global underlying object would have been a capture were it to alias the global, we can firmly conclude no-alias. It isn't reasonable for a transformation to introduce a capture in a way observable by an alias analysis. Consider, even if it were to temporarily capture one globals address into another global and then restore the other global afterward, there would be no way for the load in the alias query to observe that capture event correctly. If it observes it then the temporary capturing would have changed the meaning of the program, making it an invalid transformation. Even instrumentation passes or a pass which is synthesizing stores to global variables to expose race conditions in programs could not trigger this unless it queried the alias analysis infrastructure mid-transform, in which case it seems reasonable to return results from before the transform started. See the comments in the change for a more detailed outlining of the theory here. This should address the primary performance regression found when the non-conservatively-correct path of the alias query was disabled. Differential Revision: http://reviews.llvm.org/D11410 llvm-svn: 243405
* [GMR] Fix a long-standing bug in GlobalsModRef where it failed to clearChandler Carruth2015-07-281-4/+30
| | | | | | | | | | | | | | | | | | | | | | | | out the per-function modref data structures when functions were deleted or when globals were deleted. I don't actually know how the global deletion side of this bug hasn't been hit before, but for the other it just-so-happens that functions aren't likely to be deleted in the particular part of the LTO pipeline where we currently enable GMR, so we got lucky. With this patch, I can self-host with GMR enabled in the normal pass pipeline! I was a bit concerned about the compile-time impact of this chang, which is part of what motivated my prior string of patches to make the per-function datastructure very dense and fast to walk. With those changes in place, I can't measure a significant compile time difference (the difference is around 0.1% which is *way* below the noise) before and after this patch when building a linked bitcode for all of Clang. Differential Revision: http://reviews.llvm.org/D11453 llvm-svn: 243385
* [LAA] Split out a helper to print a collection of memchecksAdam Nemet2015-07-271-34/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is effectively an NFC but we can no longer print the index of the pointer group so instead I print its address. This still lets us cross-check the section that list the checks against the section that list the groups (see how I modified the test). E.g. before we printed this: Run-time memory checks: Check 0: Comparing group 0: %arrayidxC = getelementptr inbounds i16, i16* %c, i64 %store_ind %arrayidxC1 = getelementptr inbounds i16, i16* %c, i64 %store_ind_inc Against group 1: %arrayidxA = getelementptr i16, i16* %a, i64 %ind %arrayidxA1 = getelementptr i16, i16* %a, i64 %add ... Grouped accesses: Group 0: (Low: %c High: (78 + %c)) Member: {%c,+,4}<%for.body> Member: {(2 + %c),+,4}<%for.body> Now we print this (changes are underlined): Run-time memory checks: Check 0: Comparing group (0x7f9c6040c320): ~~~~~~~~~~~~~~ %arrayidxC1 = getelementptr inbounds i16, i16* %c, i64 %store_ind_inc %arrayidxC = getelementptr inbounds i16, i16* %c, i64 %store_ind Against group (0x7f9c6040c358): ~~~~~~~~~~~~~~ %arrayidxA1 = getelementptr i16, i16* %a, i64 %add %arrayidxA = getelementptr i16, i16* %a, i64 %ind ... Grouped accesses: Group 0x7f9c6040c320: ~~~~~~~~~~~~~~ (Low: %c High: (78 + %c)) Member: {(2 + %c),+,4}<%for.body> Member: {%c,+,4}<%for.body> llvm-svn: 243354
* [TargetTransformInfo][NFCI] Add TargetTransformInfo::isZExtFree.Sanjoy Das2015-07-271-0/+4
| | | | | | | | | | | | | | Summary: This function is not used in this change but will be used in a subsequent change. Reviewers: mcrosier, chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9180 llvm-svn: 243347
* [IndVars] Make loop varying predicates loop invariant.Sanjoy Das2015-07-271-0/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Was D9784: "Remove loop variant range check when induction variable is strictly increasing" This change re-implements D9784 with the two differences: 1. It does not use SCEVExpander and does not generate new instructions. Instead, it does a quick local search for existing `llvm::Value`s that it needs when modifying the `icmp` instruction. 2. It is more general -- it deals with both increasing and decreasing induction variables. I've added all of the tests included with D9784, and two more. As an example on what this change does (copied from D9784): Given C code: ``` for (int i = M; i < N; i++) // i is known not to overflow if (i < 0) break; a[i] = 0; } ``` This transformation produces: ``` for (int i = M; i < N; i++) if (M < 0) break; a[i] = 0; } ``` Which can be unswitched into: ``` if (!(M < 0)) for (int i = M; i < N; i++) a[i] = 0; } ``` I went back and forth on whether the top level logic should live in `SimplifyIndvar::eliminateIVComparison` or be put into its own routine. Right now I've put it under `eliminateIVComparison` because even though the `icmp` is not *eliminated*, it no longer is an IV comparison. I'm open to putting it in its own helper routine if you think that is better. Reviewers: reames, nicholas, atrick Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11278 llvm-svn: 243331
* [LAA] Upper-case variable names, NFCAdam Nemet2015-07-271-4/+4
| | | | llvm-svn: 243313
* [LAA] Split out a helper from addRuntimeCheck to generate the check, NFCAdam Nemet2015-07-271-14/+18
| | | | llvm-svn: 243312
* Fix assert when inlining a constantexpr addrspacecastMatt Arsenault2015-07-271-2/+1
| | | | | | | | | | | | The pointer size of the addrspacecasted pointer might not have matched, so this would have hit an assert in accumulateConstantOffset. I think this was here to allow constant folding of a load of an addrspacecasted constant. Accumulating the offset through the addrspacecast doesn't make much sense, so something else is necessary to allow folding the load through this cast. llvm-svn: 243300
* LoopAccessAnalysis.cpp: Tweak r243239 to avoid side effects. It caused ↵NAKAMURA Takumi2015-07-271-3/+4
| | | | | | different emissions between gcc and clang. llvm-svn: 243258
* Roll forward r243250Jingyue Wu2015-07-261-4/+2
| | | | | | | | | r243250 appeared to break clang/test/Analysis/dead-store.c on one of the build slaves, but I couldn't reproduce this failure locally. Probably a false positive as I saw this test was broken by r243246 or r243247 too but passed later without people fixing anything. llvm-svn: 243253
* Revert r243250Jingyue Wu2015-07-261-2/+4
| | | | | | breaks tests llvm-svn: 243251
* [TTI/CostModel] improve TTI::getGEPCost and use it in ↵Jingyue Wu2015-07-261-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CostModel::getInstructionCost Summary: This patch updates TargetTransformInfoImplCRTPBase::getGEPCost to consider addressing modes. It now returns TCC_Free when the GEP can be completely folded to an addresing mode. I started this patch as I refactored SLSR. Function isGEPFoldable looks common and is indeed used by some WIP of mine. So I extracted that logic to getGEPCost. Furthermore, I noticed getGEPCost wasn't directly tested anywhere. The best testing bed seems CostModel, but its getInstructionCost method invokes getAddressComputationCost for GEPs which provides very coarse estimation. So this patch also makes getInstructionCost call the updated getGEPCost for GEPs. This change inevitably breaks some tests because the cost model changes, but nothing looks seriously wrong -- if we believe the new cost model is the right way to go, these tests should be updated. This patch is not perfect yet -- the comments in some tests need to be updated. I want to know whether this is a right approach before fixing those details. Reviewers: chandlerc, hfinkel Subscribers: aschwaighofer, llvm-commits, aemerson Differential Revision: http://reviews.llvm.org/D9819 llvm-svn: 243250
* [LAA] Begin moving the logic of generating checks out of addRuntimeCheckAdam Nemet2015-07-261-69/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The goal is to start moving us closer to the model where RuntimePointerChecking will compute and store the checks. Then a client can filter the check according to its requirements and then use the filtered list of checks with addRuntimeCheck. Before the patch, this is all done in addRuntimeCheck. So the patch starts to split up addRuntimeCheck while providing the old API under what's more or less a wrapper now. The new underlying addRuntimeCheck takes a collection of checks now, expands the code for the bounds then generates the code for the checks. I am not completely happy with making expandBounds static because now it needs so many explicit arguments but I don't want to make the type PointerBounds part of LAI. This should get fixed when addRuntimeCheck is moved to LoopVersioning where it really belongs, IMO. Audited the assembly diff of the testsuite (including externals). There is a tiny bit of assembly churn that is due to the different order the code for the bounds is expanded now (MultiSource/Benchmarks/Prolangs-C/bison/conflicts.s and with LoopDist on 456.hmmer/fast_algorithms.s). Reviewers: hfinkel Subscribers: klimek, llvm-commits Differential Revision: http://reviews.llvm.org/D11205 llvm-svn: 243239
* [GMR] Switch the function info we store for every function to be a muchChandler Carruth2015-07-231-23/+91
| | | | | | | | | | | | | | more dense datastructure. We actually only have 3 bits of information and an often-null pointer here. This fits very nicely into a pointer-size value in the DenseMap from Function -> Info. Then we take one more pointer hop to get to a secondary DenseMap from GlobalValue -> ModRefInfo when we actually have precise info for particular globals. This is more code than I would really like to do this packing, but it ended up reasonably cleanly laid out. It should ensure we don't hit scaling limitations with more widespread use of GMR. llvm-svn: 242991
* [ScalarEvolution] Change addRequired to addRequiredTransitive on two passes ↵Craig Topper2015-07-231-2/+2
| | | | | | | | | | | where ScalarEvolution stores long lived raw pointers to objects those passes own. This prevents the pointers from dangling when those passes are freed. http://reviews.llvm.org/D11236 Patch by Steve King. llvm-svn: 242989
* [GMR] Further improve the FunctionInfo API inside of GlobalsModRef, NFC.Chandler Carruth2015-07-231-24/+21
| | | | | | | | | | | | | This takes the operation of merging a callee's information into the current information and embeds it into the FunctionInfo type itself. This is much cleaner as now we don't need to expose iteration of the globals, etc. Also, switched all the uses of a raw integer two maintain the mod/ref info during the SCC walk into just directly manipulating it in the FunctionInfo object. llvm-svn: 242976
* [GMR] Wrap all of the per-function information behind a more stronglyChandler Carruth2015-07-221-63/+92
| | | | | | | | | | | typed interface as a precursor to rewriting how it is stored. This way we know that the access paths are controlled and it should be easy to store these bits in a different way. No functionality changed. llvm-svn: 242974
* [PM/AA] Extract the ModRef enums from the AliasAnalysis class inChandler Carruth2015-07-2213-309/+309
| | | | | | | | | | | | | | | | | | | | | | | 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
* [GMR] Continue my quest to remove linked datastructures from GMR, NFC.Chandler Carruth2015-07-221-3/+2
| | | | | | | | | This replaces the next-to-last std::map with a DenseMap. While DenseMap doesn't yet make tons of sense (there are 32 bytes or so in the value type), my next change will reduce the value type to a single pointer -- we only need a pointer and 3 bits, and that is exactly what we can have. llvm-svn: 242956
* [ConstantFolding] Support folding loads from a GlobalAliasDavid Majnemer2015-07-221-0/+4
| | | | | | | | | | | | | | The MSVC ABI requires that we generate an alias for the vtable which means looking through a GlobalAlias which cannot be overridden improves our ability to devirtualize. Found while investigating PR20801. Patch by Andrew Zhogin! Differential Revision: http://reviews.llvm.org/D11306 llvm-svn: 242955
* [GMR] Make the collection of readers and writers of globals much moreChandler Carruth2015-07-221-20/+22
| | | | | | | | | | | | | | | | | | | | | | | efficient, NFC. Previously, we built up vectors of function pointers to track readers and writers. The primary problem here is that we would add the same function to this vector every time we found an instruction that reads or writes to the pointer. This could be a *lot* of redudant function pointers. Instead of doing that, we can use a SmallPtrSet. This does more than just reduce the size of the list of readers or writers. We walk the entire lists of each and do a map lookup for each one. By having sets, we will only do one map lookup per reader or writer function. But only one user of the pointer analyzer actually needs this information, so we can also skip accumulating it (and doing a lot of heap allocations) for all the other pointer analysis. This is particularly useful because there are very many more pointers in some of the other cases. llvm-svn: 242950
* Fix -Wextra-semi warnings.Hans Wennborg2015-07-221-1/+1
| | | | | | | | Patch by Eugene Zelenko! Differential Revision: http://reviews.llvm.org/D11400 llvm-svn: 242930
* [GMR] Switch from std::set to SmallPtrSet. NFC.Chandler Carruth2015-07-221-3/+3
| | | | | | | | | This almost certainly doesn't matter in some deep sense, but std::set is essentially always going to be slower here. Now the alias query should be essentially constant time instead of having to chase the set tree each time. llvm-svn: 242893
* [GMR] Only look in the associated allocs map for an underlying value ifChandler Carruth2015-07-221-4/+4
| | | | | | | | it wasn't one of the indirect globals (which clearly cannot be an allocation function call). Also only do a single lookup into this map instead of two. NFC. llvm-svn: 242892
* [GMR] Switch to a DenseMap and clean up the iteration loop. NFC.Chandler Carruth2015-07-221-11/+6
| | | | | | | | | | | | | Since we have to iterate this map not that infrequently, we should use a map that is efficient for iteration. It is also almost certainly much faster for lookups as well. There is more to do in terms of reducing the wasted overhead of GMR's runtime though. Not sure how much is worthwhile though. The loop improvements should hopefully address the code review that Duncan gave when he saw this code as I moved it around. llvm-svn: 242891
* [PM/AA] Try to fix libc++ build bots which require the type used inChandler Carruth2015-07-221-40/+39
| | | | | | | std::list to be complete by hoisting the entire definition into the class. Ugly, but hopefully works. llvm-svn: 242888
* [PM/AA] Remove the last of the legacy update API from AliasAnalysis asChandler Carruth2015-07-225-17/+0
| | | | | | | | | | | | | 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
* [PM/AA] Put the 'final' keyword in the correct place. And actuallyChandler Carruth2015-07-221-1/+1
| | | | | | succeed at compiling my change before committing it too! llvm-svn: 242879
* [PM/AA] Replace the only use of the AliasAnalysis::deleteValue API (inChandler Carruth2015-07-221-35/+58
| | | | | | | | | | | | | | | | | | | | | | GlobalsModRef) with CallbackVHs that trigger the same behavior. This is technically more expensive, but in benchmarking some LTO runs, it seems unlikely to even be above the noise floor. The only way I was able to measure the performance of GMR at all was to run nothing else but this one analysis on a linked clang bitcode file. The call graph analysis still took 5x more time than GMR, and this change at most made GMR 2% slower (this is well within the noise, so its hard for me to be sure that this is an actual change). However, in a real LTO run over the same bitcode, the GMR run takes so little time that the pass timers don't measure it. With this, I can remove the last update API from the AliasAnalysis interface, but I'll actually remove the interface hook point in a follow-up commit. Differential Revision: http://reviews.llvm.org/D11324 llvm-svn: 242878
OpenPOWER on IntegriCloud