History log of /llvm-project/llvm/lib/Analysis/BasicAliasAnalysis.cpp (Results 426 – 450 of 785)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# b94011fd 14-Jul-2013 Craig Topper <craig.topper@gmail.com>

Use SmallVectorImpl& instead of SmallVector to avoid repeating small vector size.

llvm-svn: 186274


Revision tags: llvmorg-3.3.1-rc1, llvmorg-3.3.0, llvmorg-3.3.0-rc3
# f3e663af 28-May-2013 Michael Kuperstein <michael.m.kuperstein@intel.com>

Make BasicAliasAnalysis recognize the fact a noalias argument cannot alias another argument, even if the other argument is not itself marked noalias.

llvm-svn: 182755


Revision tags: llvmorg-3.3.0-rc2, llvmorg-3.3.0-rc1
# abcc64fd 09-Apr-2013 Nadav Rotem <nrotem@apple.com>

Revert r176408 and r176407 to address PR15540.

llvm-svn: 179111


# aadf1043 26-Mar-2013 Arnold Schwaighofer <aschwaighofer@apple.com>

BasicAA: Only query twice if the result of the more general query was MayAlias

This is a compile time optimization. Before the patch we would do two traversals
on each call to aliasGEP - one with a

BasicAA: Only query twice if the result of the more general query was MayAlias

This is a compile time optimization. Before the patch we would do two traversals
on each call to aliasGEP - one with a set size parameter one with UnknownSize.
We can do better by first checking the result of the alias query with
UnknownSize.
Only if this one returns MayAlias do we query a second time using size and type.

This recovers an about 7% compile time regression on spec/ammp.

radar://12349960

llvm-svn: 178045

show more ...


# 6e3d4601 02-Mar-2013 Nuno Lopes <nunoplopes@sapo.pt>

add getUnderlyingObjectSize()
this is similar to getObjectSize(), but doesnt subtract the offset
tweak the BasicAA code accordingly (per PR14988)

llvm-svn: 176407


# 1e55d8c6 28-Feb-2013 Shuxin Yang <shuxin.llvm@gmail.com>

Fix a problem in alias analysis. It is about the misinterpretation of "Object".

This problem is exposed by r171325 which is already reverted. It is rather
hard to fabricate a testing case without it

Fix a problem in alias analysis. It is about the misinterpretation of "Object".

This problem is exposed by r171325 which is already reverted. It is rather
hard to fabricate a testing case without it.

r171325 should *NOT* be resurrected as it has a potential problem although
this problem dosen't directly contribute to PR14988.

The bug is tracked by:
- rdar://13063553, and
- http://llvm.org/bugs/show_bug.cgi?id=14988

Thank Arnold for coming up a better solution to this problem. After
comparing this solution and my original proposal, I decided to ditch mine.

llvm-svn: 176225

show more ...


# db25c6cf 02-Jan-2013 Chandler Carruth <chandlerc@gmail.com>

Actually update the CMake and Makefile builds correctly, and update the
code that includes Intrinsics.gen directly.

This never showed up in my testing because the old Intrinsics.gen was
still kickin

Actually update the CMake and Makefile builds correctly, and update the
code that includes Intrinsics.gen directly.

This never showed up in my testing because the old Intrinsics.gen was
still kicking around in the make build system and was correct there. =[
Thankfully, some of the bots to clean rebuilds and that caught this.

llvm-svn: 171373

show more ...


# 9fb823bb 02-Jan-2013 Chandler Carruth <chandlerc@gmail.com>

Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long

Move all of the header files which are involved in modelling the LLVM IR
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

show more ...


Revision tags: llvmorg-3.2.0
# edd62b14 10-Dec-2012 Arnold Schwaighofer <arnolds@codeaurora.org>

Optimistically analyse Phi cycles

Analyse Phis under the starting assumption that they are NoAlias. Recursively
look at their inputs.
If they MayAlias/MustAlias there must be an input that makes the

Optimistically analyse Phi cycles

Analyse Phis under the starting assumption that they are NoAlias. Recursively
look at their inputs.
If they MayAlias/MustAlias there must be an input that makes them so.

Addresses bug 14351.

llvm-svn: 169788

show more ...


Revision tags: llvmorg-3.2.0-rc3
# ed0881b2 03-Dec-2012 Chandler Carruth <chandlerc@gmail.com>

Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module

Use the new script to sort the includes of every file under lib.

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

show more ...


Revision tags: llvmorg-3.2.0-rc2
# a6f86fc6 17-Nov-2012 Hal Finkel <hfinkel@anl.gov>

Phi speculation improvement for BasicAA

This is a partial solution to PR14351. It removes some of the special
significance of the first incoming phi value in the phi aliasing checking logic
in Basic

Phi speculation improvement for BasicAA

This is a partial solution to PR14351. It removes some of the special
significance of the first incoming phi value in the phi aliasing checking logic
in BasicAA. In the context of a loop, the old logic assumes that the first
incoming value is the interesting one (meaning that it is the one that comes
from outside the loop), but this is often not the case. With this change, we
now test first the incoming value that comes from a block other than the parent
of the phi being tested.

llvm-svn: 168245

show more ...


Revision tags: llvmorg-3.2.0-rc1
# a1fffcf7 05-Nov-2012 Richard Osborne <richard@xmos.com>

Don't infer whether a value is captured in the current function from the
'nocapture' attribute.

The nocapture attribute only specifies that no copies are made that
outlive the function. This isn't t

Don't infer whether a value is captured in the current function from the
'nocapture' attribute.

The nocapture attribute only specifies that no copies are made that
outlive the function. This isn't the same as there being no copies at all.
This fixes PR14045.

llvm-svn: 167381

show more ...


# 71c2070e 04-Nov-2012 Duncan Sands <baldrick@free.fr>

Apply the patch from PR14160. I failed to construct a testcase for this, but
I'm applying it anyway since it seems to be obviously correct.

llvm-svn: 167370


# 5da3f051 01-Nov-2012 Chandler Carruth <chandlerc@gmail.com>

Revert the majority of the next patch in the address space series:

r165941: Resubmit the changes to llvm core to update the functions to
support different pointer sizes on a per address spa

Revert the majority of the next patch in the address space series:

r165941: Resubmit the changes to llvm core to update the functions to
support different pointer sizes on a per address space basis.

Despite this commit log, this change primarily changed stuff outside of
VMCore, and those changes do not carry any tests for correctness (or
even plausibility), and we have consistently found questionable or flat
out incorrect cases in these changes. Most of them are probably correct,
but we need to devise a system that makes it more clear when we have
handled the address space concerns correctly, and ideally each pass that
gets updated would receive an accompanying test case that exercises that
pass specificaly w.r.t. alternate address spaces.

However, from this commit, I have retained the new C API entry points.
Those were an orthogonal change that probably should have been split
apart, but they seem entirely good.

In several places the changes were very obvious cleanups with no actual
multiple address space code added; these I have not reverted when
I spotted them.

In a few other places there were merge conflicts due to a cleaner
solution being implemented later, often not using address spaces at all.
In those cases, I've preserved the new code which isn't address space
dependent.

This is part of my ongoing effort to clean out the partial address space
code which carries high risk and low test coverage, and not likely to be
finished before the 3.2 release looms closer. Duncan and I would both
like to see the above issues addressed before we return to these
changes.

llvm-svn: 167222

show more ...


# 4bb926d9 15-Oct-2012 Micah Villmow <villmow@gmail.com>

Resubmit the changes to llvm core to update the functions to support different pointer sizes on a per address space basis.

llvm-svn: 165941


# 0c61134d 11-Oct-2012 Micah Villmow <villmow@gmail.com>

Revert 165732 for further review.

llvm-svn: 165747


# 08318973 11-Oct-2012 Micah Villmow <villmow@gmail.com>

Add in the first iteration of support for llvm/clang/lldb to allow variable per address space pointer sizes to be optimized correctly.

llvm-svn: 165726


# cdfe20b9 08-Oct-2012 Micah Villmow <villmow@gmail.com>

Move TargetData to DataLayout.

llvm-svn: 165402


# aef83e5f 19-Sep-2012 Duncan Sands <baldrick@free.fr>

GCC doesn't understand that OrigAliasResult having a value is correlated with
ArePhisAssumedNoAlias, and warns that OrigAliasResult may be used uninitialized.
Pacify GCC.

llvm-svn: 164229


# 8dc34cfb 06-Sep-2012 Arnold Schwaighofer <arnolds@codeaurora.org>

BasicAA: Recognize cyclic NoAlias phis

Enhances basic alias analysis to recognize phis whose first incoming values are
NoAlias and whose other incoming values are just the phi node itself through
so

BasicAA: Recognize cyclic NoAlias phis

Enhances basic alias analysis to recognize phis whose first incoming values are
NoAlias and whose other incoming values are just the phi node itself through
some amount of recursion.

Example: With this change basicaa reports that ptr_phi and ptr_phi2 do not alias
each other.

bb:
ptr = ptr2 + 1

loop:
ptr_phi = phi [bb, ptr], [loop, ptr_plus_one]
ptr2_phi = phi [bb, ptr2], [loop, ptr2_plus_one]
...
ptr_plus_one = gep ptr_phi, 1
ptr2_plus_one = gep ptr2_phi, 1

This enables the elimination of one load in code like the following:

extern int foo;

int test_noalias(int *ptr, int num, int* coeff) {
int *ptr2 = ptr;
int result = (*ptr++) * (*coeff--);
while (num--) {
*ptr2++ = *ptr;
result += (*coeff--) * (*ptr++);
}
*ptr = foo;
return result;
}

Part 2/2 of fix for PR13564.

llvm-svn: 163319

show more ...


# 76dca58c 06-Sep-2012 Arnold Schwaighofer <arnolds@codeaurora.org>

BasicAA: GEPs of NoAlias'ing base ptr with equivalent indices are NoAlias

If we can show that the base pointers of two GEPs don't alias each other using
precise analysis and the indices and base off

BasicAA: GEPs of NoAlias'ing base ptr with equivalent indices are NoAlias

If we can show that the base pointers of two GEPs don't alias each other using
precise analysis and the indices and base offset are equal then the two GEPs
also don't alias each other.
This is primarily needed for the follow up patch that analyses NoAlias'ing PHI
nodes.

Part 1/2 of fix for PR13564.

llvm-svn: 163317

show more ...


# 6c2649ca 05-Sep-2012 Benjamin Kramer <benny.kra@googlemail.com>

Switch BasicAliasAnalysis' cache to SmallDenseMap.

It relies on clear() being fast and the cache rarely has more than 1 or 2
elements, so give it an inline capacity and always shrink it back down in

Switch BasicAliasAnalysis' cache to SmallDenseMap.

It relies on clear() being fast and the cache rarely has more than 1 or 2
elements, so give it an inline capacity and always shrink it back down in case
it grows. DenseMap will grow to 64 buckets which makes clear() a lot slower.

llvm-svn: 163215

show more ...


# 8bcc9711 29-Aug-2012 Benjamin Kramer <benny.kra@googlemail.com>

Make MemoryBuiltins aware of TargetLibraryInfo.

This disables malloc-specific optimization when -fno-builtin (or -ffreestanding)
is specified. This has been a problem for a long time but became more

Make MemoryBuiltins aware of TargetLibraryInfo.

This disables malloc-specific optimization when -fno-builtin (or -ffreestanding)
is specified. This has been a problem for a long time but became more severe
with the recent memory builtin improvements.

Since the memory builtin functions are used everywhere, this required passing
TLI in many places. This means that functions that now have an optional TLI
argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead
mallocs anymore if the TLI argument is missing. I've updated most passes to do
the right thing.

Fixes PR13694 and probably others.

llvm-svn: 162841

show more ...


# 55fff834 21-Jun-2012 Nuno Lopes <nunoplopes@sapo.pt>

refactor the MemoryBuiltin analysis:
- provide more extensive set of functions to detect library allocation functions (e.g., malloc, calloc, strdup, etc)
- provide an API to compute the size and of

refactor the MemoryBuiltin analysis:
- provide more extensive set of functions to detect library allocation functions (e.g., malloc, calloc, strdup, etc)
- provide an API to compute the size and offset of an object pointed by

Move a few clients (GVN, AA, instcombine, ...) to the new API.
This implementation is a lot more aggressive than each of the custom implementations being replaced.

Patch reviewed by Nick Lewycky and Chandler Carruth, thanks.

llvm-svn: 158919

show more ...


Revision tags: llvmorg-3.1.0, llvmorg-3.1.0-rc3, llvmorg-3.1.0-rc2, llvmorg-3.1.0-rc1
# 0774902a 27-Feb-2012 Eli Friedman <eli.friedman@gmail.com>

Duncan pointed out that if the alignment isn't explicitly specified, it defaults to the ABI alignment. Given that, make this code a bit more aggressive in such cases.

llvm-svn: 151584


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