#
c41404a0 |
| 17-Jun-2015 |
Chandler Carruth <chandlerc@gmail.com> |
[PM/AA] Split the location computation out of getArgLocation so the virtual interface on AliasAnalysis only deals with ModRef information.
This interface was both computing memory locations by using
[PM/AA] Split the location computation out of getArgLocation so the virtual interface on AliasAnalysis only deals with ModRef information.
This interface was both computing memory locations by using TLI and other tricks to estimate the size of memory referenced by an operand, and computing ModRef information through similar investigations. This change narrows the scope of the virtual interface on AliasAnalysis slightly.
Note that all of this code could live in BasicAA, and be done with a single investigation of the argument, if it weren't for the fact that the generic code in AliasAnalysis::getModRefBehavior for a callsite calls into the virtual aspect of (now) getArgModRefInfo. But this patch's arrangement seems a not terrible way to go for now.
The other interesting wrinkle is how we could reasonably extend LLVM with support for custom memory location sizes and mod/ref behavior for library routines. After discussions with Hal on the review, the conclusion is that this would be best done by fleshing out the much desired support for extensions to TLI, and support these types of queries in that interface where we would likely be doing other library API recognition and analysis.
Differential Revision: http://reviews.llvm.org/D10259
llvm-svn: 239884
show more ...
|
#
2ecb8dc3 |
| 22-May-2015 |
Hans Wennborg <hans@hanshq.net> |
Revert r236894 "[BasicAA] Fix zext & sext handling"
This seems to have caused PR23626: Clang miscompiles webkit's base64 decoder
llvm-svn: 237984
|
#
9e1d3356 |
| 20-May-2015 |
Pete Cooper <peter_cooper@apple.com> |
Change Function::getIntrinsicID() to return an Intrinsic::ID. NFC.
Now that Intrinsic::ID is a typed enum, we can forward declare it and so return it from this method.
This updates all users which
Change Function::getIntrinsicID() to return an Intrinsic::ID. NFC.
Now that Intrinsic::ID is a typed enum, we can forward declare it and so return it from this method.
This updates all users which were either using an unsigned to store it, or had a now unnecessary cast.
llvm-svn: 237810
show more ...
|
Revision tags: llvmorg-3.6.1 |
|
#
833f34d8 |
| 12-May-2015 |
Pete Cooper <peter_cooper@apple.com> |
Convert PHI getIncomingValue() to foreach over incoming_values(). NFC.
We already had a method to iterate over all the incoming values of a PHI. This just changes all eligible code to use it.
Ine
Convert PHI getIncomingValue() to foreach over incoming_values(). NFC.
We already had a method to iterate over all the incoming values of a PHI. This just changes all eligible code to use it.
Ineligible code included anything which cared about the index, or was also trying to get the i'th incoming BB.
llvm-svn: 237169
show more ...
|
Revision tags: llvmorg-3.6.1-rc1 |
|
#
14f5080a |
| 08-May-2015 |
Sanjoy Das <sanjoy@playingwithpointers.com> |
[BasicAA] Fix zext & sext handling
Summary:
There are several unhandled edge cases in BasicAA's GetLinearExpression method. This changes fixes outstanding issues, including zext / sext of a constan
[BasicAA] Fix zext & sext handling
Summary:
There are several unhandled edge cases in BasicAA's GetLinearExpression method. This changes fixes outstanding issues, including zext / sext of a constant with the sign bit set, and the refusal to decompose zexts or sexts of wrapping arithmetic.
Test Plan: Unit tests added in //q.ext.ll//.
Patch by Nick White.
Reviewers: hfinkel, sanjoy
Reviewed By: hfinkel, sanjoy
Subscribers: sanjoy, llvm-commits, hfinkel
Differential Revision: http://reviews.llvm.org/D6682
llvm-svn: 236894
show more ...
|
#
3459d6ea |
| 05-May-2015 |
Daniel Berlin <dberlin@dberlin.org> |
Update BasicAliasAnalysis to understand that nothing aliases with undef values. It got this in some cases (if one of them was an identified object), but not in all cases.
This caused stores to undef
Update BasicAliasAnalysis to understand that nothing aliases with undef values. It got this in some cases (if one of them was an identified object), but not in all cases.
This caused stores to undef to block load-forwarding in some cases, etc.
Added test to Transforms/GVN to verify optimization occurs as expected.
llvm-svn: 236511
show more ...
|
#
d288fb86 |
| 30-Mar-2015 |
David Blaikie <dblaikie@gmail.com> |
[opaque pointer type] Change GetElementPtrInst::getIndexedType to take the pointee type
This pushes the use of PointerType::getElementType up into several callers - I'll essentially just have to kee
[opaque pointer type] Change GetElementPtrInst::getIndexedType to take the pointee type
This pushes the use of PointerType::getElementType up into several callers - I'll essentially just have to keep pushing that up the stack until I can eliminate every call to it...
llvm-svn: 233604
show more ...
|
#
9e77de2a |
| 20-Mar-2015 |
Daniel Berlin <dberlin@dberlin.org> |
Small optimization to avoid getting pass info when we will not run loop
llvm-svn: 232826
|
Revision tags: llvmorg-3.5.2, llvmorg-3.5.2-rc1 |
|
#
a28d91d8 |
| 10-Mar-2015 |
Mehdi Amini <mehdi.amini@apple.com> |
DataLayout is mandatory, update the API to reflect it with references.
Summary: Now that the DataLayout is a mandatory part of the module, let's start cleaning the codebase. This patch is a first at
DataLayout is mandatory, update the API to reflect it with references.
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
show more ...
|
#
46a43556 |
| 04-Mar-2015 |
Mehdi Amini <mehdi.amini@apple.com> |
Make DataLayout Non-Optional in the Module
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
Make DataLayout Non-Optional in the Module
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
show more ...
|
Revision tags: llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3 |
|
#
29efe3b2 |
| 07-Feb-2015 |
Ahmed Bougacha <ahmed.bougacha@gmail.com> |
[BasicAA] Try to disambiguate GEPs through arrays of structs into different fields.
We can show that two GEPs off of the same (possibly multidimensional) array of structs, into different fields, can
[BasicAA] Try to disambiguate GEPs through arrays of structs into different fields.
We can show that two GEPs off of the same (possibly multidimensional) array of structs, into different fields, can't alias. Quoting:
For two GEPOperators GEP1 and GEP2, if we find that: - both GEPs begin indexing from the exact same pointer; - the last indices in both GEPs are constants, indexing into a struct; - said indices are different, hence,the pointed-to fields are different; - and both GEPs only index through arrays prior to that;
this lets us determine that the struct that GEP1 indexes into and the struct that GEP2 indexes into must either precisely overlap or be completely disjoint. Because they cannot partially overlap, indexing into different non-overlapping fields of the struct will never alias.
The other BasicAA::aliasGEP rules worked in some cases, but not all (for example, the i32x3 struct in the testcase). We can add this simple ad-hoc rule to complement them.
rdar://19717375 Differential Revision: http://reviews.llvm.org/D7453
llvm-svn: 228498
show more ...
|
Revision tags: llvmorg-3.6.0-rc2 |
|
#
4f8f307c |
| 17-Jan-2015 |
Chandler Carruth <chandlerc@gmail.com> |
[PM] Split the LoopInfo object apart from the legacy pass, creating a LoopInfoWrapperPass to wire the object up to the legacy pass manager.
This switches all the clients of LoopInfo over and paves t
[PM] Split the LoopInfo object apart from the legacy pass, creating a LoopInfoWrapperPass to wire the object up to the legacy pass manager.
This switches all the clients of LoopInfo over and paves the way to port LoopInfo to the new pass manager. No functionality change is intended with this iteration.
llvm-svn: 226373
show more ...
|
#
b98f63db |
| 15-Jan-2015 |
Chandler Carruth <chandlerc@gmail.com> |
[PM] Separate the TargetLibraryInfo object from the immutable pass.
The pass is really just a means of accessing a cached instance of the TargetLibraryInfo object, and this way we can re-use that ob
[PM] Separate the TargetLibraryInfo object from the immutable pass.
The pass is really just a means of accessing a cached instance of the TargetLibraryInfo object, and this way we can re-use that object for the new pass manager as its result.
Lots of delta, but nothing interesting happening here. This is the common pattern that is developing to allow analyses to live in both the old and new pass manager -- a wrapper pass in the old pass manager emulates the separation intrinsic to the new pass manager between the result and pass for analyses.
llvm-svn: 226157
show more ...
|
Revision tags: llvmorg-3.6.0-rc1 |
|
#
62d4215b |
| 15-Jan-2015 |
Chandler Carruth <chandlerc@gmail.com> |
[PM] Move TargetLibraryInfo into the Analysis library.
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 targe
[PM] Move TargetLibraryInfo into the Analysis library.
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
show more ...
|
#
66b3130c |
| 04-Jan-2015 |
Chandler Carruth <chandlerc@gmail.com> |
[PM] Split the AssumptionTracker immutable pass into two separate APIs: a cache of assumptions for a single function, and an immutable pass that manages those caches.
The motivation for this change
[PM] Split the AssumptionTracker immutable pass into two separate APIs: a cache of assumptions for a single function, and an immutable pass that manages those caches.
The motivation for this change is two fold. Immutable analyses are really hacks around the current pass manager design and don't exist in the new design. This is usually OK, but it requires that the core logic of an immutable pass be reasonably partitioned off from the pass logic. This change does precisely that. As a consequence it also paves the way for the *many* utility functions that deal in the assumptions to live in both pass manager worlds by creating an separate non-pass object with its own independent API that they all rely on. Now, the only bits of the system that deal with the actual pass mechanics are those that actually need to deal with the pass mechanics.
Once this separation is made, several simplifications become pretty obvious in the assumption cache itself. Rather than using a set and callback value handles, it can just be a vector of weak value handles. The callers can easily skip the handles that are null, and eventually we can wrap all of this up behind a filter iterator.
For now, this adds boiler plate to the various passes, but this kind of boiler plate will end up making it possible to port these passes to the new pass manager, and so it will end up factored away pretty reasonably.
llvm-svn: 225131
show more ...
|
Revision tags: llvmorg-3.5.1, llvmorg-3.5.1-rc2, llvmorg-3.5.1-rc1 |
|
#
70573dcd |
| 19-Nov-2014 |
David Blaikie <dblaikie@gmail.com> |
Update SetVector to rely on the underlying set's insert to return a pair<iterator, bool>
This is to be consistent with StringSet and ultimately with the standard library's associative container inse
Update SetVector to rely on the underlying set's insert to return a 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
show more ...
|
#
45ba2c10 |
| 13-Nov-2014 |
Hal Finkel <hfinkel@anl.gov> |
Revert r219432 - "Revert "[BasicAA] Revert "Revert r218714 - Make better use of zext and sign information."""
Let's try this again...
This reverts r219432, plus a bug fix.
Description of the bug i
Revert r219432 - "Revert "[BasicAA] Revert "Revert r218714 - Make better use of zext and sign information."""
Let's try this again...
This reverts r219432, plus a bug fix.
Description of the bug in r219432 (by Nick):
The bug was using AllPositive to break out of the loop; if the loop break condition i != e is changed to i != e && AllPositive then the test_modulo_analysis_with_global test I've added will fail as the Modulo will be calculated incorrectly (as the last loop iteration is skipped, so Modulo isn't updated with its Scale).
Nick also adds this comment:
ComputeSignBit is safe to use in loops as it takes into account phi nodes, and the == EK_ZeroEx check is safe in loops as, no matter how the variable changes between iterations, zero-extensions will always guarantee a zero sign bit. The isValueEqualInPotentialCycles check is therefore definitely not needed as all the variable analysis holds no matter how the variables change between loop iterations.
And this patch also adds another enhancement to GetLinearExpression - basically to convert ConstantInts to Offsets (see test_const_eval and test_const_eval_scaled for the situations this improves).
Original commit message:
This reverts r218944, which reverted r218714, plus a bug fix.
Description of the bug in r218714 (by Nick):
The original patch forgot to check if the Scale in VariableGEPIndex flipped the sign of the variable. The BasicAA pass iterates over the instructions in the order they appear in the function, and so BasicAliasAnalysis::aliasGEP is called with the variable it first comes across as parameter GEP1. Adding a %reorder label puts the definition of %a after %b so aliasGEP is called with %b as the first parameter and %a as the second. aliasGEP later calculates that %a == %b + 1 - %idxprom where %idxprom >= 0 (if %a was passed as the first parameter it would calculate %b == %a - 1 + %idxprom where %idxprom >= 0) - ignoring that %idxprom is scaled by -1 here lead the patch to incorrectly conclude that %a > %b.
Revised patch by Nick White, thanks! Thanks to Lang to isolating the bug. Slightly modified by me to add an early exit from the loop and avoid unnecessary, but expensive, function calls.
Original commit message:
Two related things:
1. Fixes a bug when calculating the offset in GetLinearExpression. The code previously used zext to extend the offset, so negative offsets were converted to large positive ones.
2. Enhance aliasGEP to deduce that, if the difference between two GEP allocations is positive and all the variables that govern the offset are also positive (i.e. the offset is strictly after the higher base pointer), then locations that fit in the gap between the two base pointers are NoAlias.
Patch by Nick White!
llvm-svn: 221876
show more ...
|
#
cbbd3df8 |
| 09-Oct-2014 |
Hal Finkel <hfinkel@anl.gov> |
Revert "[BasicAA] Revert "Revert r218714 - Make better use of zext and sign information.""
This reverts commit r219135 -- still causing miscompiles in SPEC it seems...
llvm-svn: 219432
|
#
43ce71f1 |
| 06-Oct-2014 |
Hal Finkel <hfinkel@anl.gov> |
[BasicAA] Revert "Revert r218714 - Make better use of zext and sign information."
This reverts r218944, which reverted r218714, plus a bug fix.
Description of the bug in r218714 (by Nick)
The orig
[BasicAA] Revert "Revert r218714 - Make better use of zext and sign information."
This reverts r218944, which reverted r218714, plus a bug fix.
Description of the bug in r218714 (by Nick)
The original patch forgot to check if the Scale in VariableGEPIndex flipped the sign of the variable. The BasicAA pass iterates over the instructions in the order they appear in the function, and so BasicAliasAnalysis::aliasGEP is called with the variable it first comes across as parameter GEP1. Adding a %reorder label puts the definition of %a after %b so aliasGEP is called with %b as the first parameter and %a as the second. aliasGEP later calculates that %a == %b + 1 - %idxprom where %idxprom >= 0 (if %a was passed as the first parameter it would calculate %b == %a - 1 + %idxprom where %idxprom >= 0) - ignoring that %idxprom is scaled by -1 here lead the patch to incorrectly conclude that %a > %b.
Revised patch by Nick White, thanks! Thanks to Lang to isolating the bug. Slightly modified by me to add an early exit from the loop and avoid unnecessary, but expensive, function calls.
Original commit message:
Two related things:
1. Fixes a bug when calculating the offset in GetLinearExpression. The code previously used zext to extend the offset, so negative offsets were converted to large positive ones.
2. Enhance aliasGEP to deduce that, if the difference between two GEP allocations is positive and all the variables that govern the offset are also positive (i.e. the offset is strictly after the higher base pointer), then locations that fit in the gap between the two base pointers are NoAlias.
Patch by Nick White!
llvm-svn: 219135
show more ...
|
#
2e52f028 |
| 04-Oct-2014 |
Benjamin Kramer <benny.kra@googlemail.com> |
Make AAMDNodes ctor and operator bool (!!!) explicit, mop up bugs and weirdness exposed by it.
llvm-svn: 219068
|
#
89e9c172 |
| 03-Oct-2014 |
Lang Hames <lhames@gmail.com> |
[BasicAA] Revert r218714 - Make better use of zext and sign information.
This patch broke 447.dealII on Darwin. I'm currently working on a reduced test-case, but reverting for now to keep the bots h
[BasicAA] Revert r218714 - Make better use of zext and sign information.
This patch broke 447.dealII on Darwin. I'm currently working on a reduced test-case, but reverting for now to keep the bots happy.
<rdar://problem/18530107>
llvm-svn: 218944
show more ...
|
#
fd863179 |
| 30-Sep-2014 |
Hal Finkel <hfinkel@anl.gov> |
[BasicAA] Make better use of zext and sign information
Two related things:
1. Fixes a bug when calculating the offset in GetLinearExpression. The code previously used zext to extend the offset
[BasicAA] Make better use of zext and sign information
Two related things:
1. Fixes a bug when calculating the offset in GetLinearExpression. The code previously used zext to extend the offset, so negative offsets were converted to large positive ones.
2. Enhance aliasGEP to deduce that, if the difference between two GEP allocations is positive and all the variables that govern the offset are also positive (i.e. the offset is strictly after the higher base pointer), then locations that fit in the gap between the two base pointers are NoAlias.
Patch by Nick White!
llvm-svn: 218714
show more ...
|
#
60db0589 |
| 07-Sep-2014 |
Hal Finkel <hfinkel@anl.gov> |
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits (and other associated functions in ValueTracking), a
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits (and other associated functions in ValueTracking), adds some (optional) parameters to computeKnownBits and friends. These functions now (optionally) take a "context" instruction pointer, an AssumptionTracker pointer, and also a DomTree pointer, and most of the changes are just to pass this new information when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties of a value might depend on the control-flow location of the use (because we care that the @llvm.assume dominates the use because assumptions have control-flow dependencies). This means that, when we ask if bits are known in a value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as with the rest of the code, new parameters need to be passed around. To make this easier, I grouped them into a structure, and I made internal static versions of the relevant functions that take this structure as a parameter. The new code does as you might expect, it looks for @llvm.assume calls that make use of the value we're trying to learn something about (often indirectly), attempts to pattern match that expression, and uses the result if successful. By making use of the AssumptionTracker, the process of finding @llvm.assume calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of already-considered @llvm.assume calls. This is to prevent a query using, for example, the assume(a == b), to recurse on itself. The context and DT params are used to find applicable assumptions. An assumption needs to dominate the context instruction, or come after it deterministically. In this latter case we only handle the specific case where both the assumption and the context instruction are in the same block, and we need to exclude assumptions from being used to simplify their own ephemeral values (those which contribute only to the assumption) because otherwise the assumption would prove its feeding comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation (just enough to write a regression test). Future commits add more patterns (and, correspondingly, more regression tests).
llvm-svn: 217342
show more ...
|
Revision tags: llvmorg-3.5.0, llvmorg-3.5.0-rc4 |
|
#
4627679c |
| 24-Aug-2014 |
Craig Topper <craig.topper@gmail.com> |
Use range based for loops to avoid needing to re-mention SmallPtrSet size.
llvm-svn: 216351
|
Revision tags: llvmorg-3.5.0-rc3, llvmorg-3.5.0-rc2 |
|
#
93046910 |
| 25-Jul-2014 |
Hal Finkel <hfinkel@anl.gov> |
Add @llvm.assume, lowering, and some basic properties
This is the first commit in a series that add an @llvm.assume intrinsic which can be used to provide the optimizer with a condition it may assum
Add @llvm.assume, lowering, and some basic properties
This is the first commit in a series that add an @llvm.assume intrinsic which can be used to provide the optimizer with a condition it may assume to be true (when the control flow would hit the intrinsic call). Some basic properties are added here:
- llvm.invariant(true) is dead. - llvm.invariant(false) is unreachable (this directly corresponds to the documented behavior of MSVC's __assume(0)), so is llvm.invariant(undef).
The intrinsic is tagged as writing arbitrarily, in order to maintain control dependencies. BasicAA has been updated, however, to return NoModRef for any particular location-based query so that we don't unnecessarily block code motion.
llvm-svn: 213973
show more ...
|