| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
exposes an initializeMyPassFunction(), which
must be called in the pass's constructor. This function uses static dependency declarations to recursively initialize
the pass's dependencies.
Clients that only create passes through the createFooPass() APIs will require no changes. Clients that want to use the
CommandLine options for passes will need to manually call the appropriate initialization functions in PassInitialization.h
before parsing commandline arguments.
I have tested this with all standard configurations of clang and llvm-gcc on Darwin. It is possible that there are problems
with the static dependencies that will only be visible with non-standard options. If you encounter any crash in pass
registration/creation, please send the testcase to me directly.
llvm-svn: 116820
|
|
|
|
|
|
|
|
|
| |
perform initialization without static constructors AND without explicit initialization
by the client. For the moment, passes are required to initialize both their
(potential) dependencies and any passes they preserve. I hope to be able to relax
the latter requirement in the future.
llvm-svn: 116334
|
|
|
|
| |
llvm-svn: 115996
|
|
|
|
|
|
|
|
|
|
|
| |
isn't a good level of abstraction for memdep. Instead, generalize
AliasAnalysis::alias and related interfaces with a new Location
class for describing a memory location. For now, this is the same
Pointer and Size as before, plus an additional field for a TBAA tag.
Also, introduce a fixed MD_tbaa metadata tag kind.
llvm-svn: 113858
|
|
|
|
| |
llvm-svn: 110460
|
|
|
|
| |
llvm-svn: 110410
|
|
|
|
|
|
|
|
| |
address of the static
ID member as the sole unique type identifier. Clean up APIs related to this change.
llvm-svn: 110396
|
|
|
|
| |
llvm-svn: 110091
|
|
|
|
|
|
| |
RegisterAnalysisGroup<> for pass registration.
llvm-svn: 109058
|
|
|
|
|
|
|
|
| |
working again. I don't see why this patch
would cause them to fail the way they are, but none of the other intervening patches seem likely either.
llvm-svn: 108818
|
|
|
|
| |
llvm-svn: 108813
|
|
|
|
|
|
|
| |
superclass (StaticPassInfo) and a constructor-ful subclass (PassInfo).", it is
breaking teh everything.
llvm-svn: 108805
|
|
|
|
|
|
| |
(StaticPassInfo) and a constructor-ful subclass (PassInfo).
llvm-svn: 108794
|
|
|
|
|
|
|
|
| |
on ScalarEvolution successfully folding and preserving
range information for both A-B and B-A. Now, if it gets
either one, it's sufficient.
llvm-svn: 107249
|
|
|
|
| |
llvm-svn: 106260
|
|
|
|
| |
llvm-svn: 97459
|
|
|
|
|
|
|
| |
and T->isPointerTy(). Convert most instances of the first form to the second form.
Requested by Chris.
llvm-svn: 96344
|
|
|
|
| |
llvm-svn: 94018
|
|
|
|
|
|
| |
underlying alias call even for non-identified-object values.
llvm-svn: 85656
|
|
|
|
|
|
| |
VISIBILITY_HIDDEN removal.
llvm-svn: 85043
|
|
|
|
|
|
|
| |
Chris claims we should never have visibility_hidden inside any .cpp file but
that's still not true even after this commit.
llvm-svn: 85042
|
|
|
|
| |
llvm-svn: 80452
|
|
This is a simple AliasAnalysis implementation which works by making
ScalarEvolution queries. ScalarEvolution has a more complete understanding
of arithmetic than BasicAA's collection of ad-hoc checks, so it handles
some cases that BasicAA misses, for example p[i] and p[i+1] within the
same iteration of a loop.
This is currently experimental. It may be that the main use for this pass
will be to help find cases where BasicAA can be profitably extended, or
to help in the development of the overall AliasAnalysis infrastructure,
however it's also possible that it could grow up to become a directly
useful pass.
llvm-svn: 80098
|