History log of /llvm-project/llvm/lib/Analysis/BasicAliasAnalysis.cpp (Results 376 – 400 of 785)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


1...<<11121314151617181920>>...32