| 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
|
|
|
|
|
|
|
|
|
|
|
|
| |
depends on the IR infrastructure, there is no sense in it being off in
Support land.
This is in preparation to start working to expand InstVisitor into more
special-purpose visitors that are still generic and can be re-used
across different passes. The expansion will go into the Analylis tree
though as nothing in VMCore needs it.
llvm-svn: 168972
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
getIntPtrType support for multiple address spaces via a pointer type,
and also introduced a crasher bug in the constant folder reported in
PR14233.
These commits also contained several problems that should really be
addressed before they are re-committed. I have avoided reverting various
cleanups to the DataLayout APIs that are reasonable to have moving
forward in order to reduce the amount of churn, and minimize the number
of commits that were reverted. I've also manually updated merge
conflicts and manually arranged for the getIntPtrType function to stay
in DataLayout and to be defined in a plausible way after this revert.
Thanks to Duncan for working through this exact strategy with me, and
Nick Lewycky for tracking down the really annoying crasher this
triggered. (Test case to follow in its own commit.)
After discussing with Duncan extensively, and based on a note from
Micah, I'm going to continue to back out some more of the more
problematic patches in this series in order to ensure we go into the
LLVM 3.2 branch with a reasonable story here. I'll send a note to
llvmdev explaining what's going on and why.
Summary of reverted revisions:
r166634: Fix a compiler warning with an unused variable.
r166607: Add some cleanup to the DataLayout changes requested by
Chandler.
r166596: Revert "Back out r166591, not sure why this made it through
since I cancelled the command. Bleh, sorry about this!
r166591: Delete a directory that wasn't supposed to be checked in yet.
r166578: Add in support for getIntPtrType to get the pointer type based
on the address space.
llvm-svn: 167221
|
|
|
|
|
|
|
|
|
| |
address space.
This checkin also adds in some tests that utilize these paths and updates some of the
clients.
llvm-svn: 166578
|
|
|
|
| |
llvm-svn: 165402
|
|
|
|
|
|
|
| |
source of false positives due to globals being declared in a header with some
kind of incomplete (small) type, but the actual definition being bigger.
llvm-svn: 164912
|
|
|
|
| |
llvm-svn: 164671
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously it was only be able to detect problems if the pointer was a numerical
value (eg inttoptr i32 1 to i32*), but not if it was an alloca or globa. The
reason was the use of ComputeMaskedBits: imagine you have "alloca i8, align 2",
and ask ComputeMaskedBits what it knows about the bits of the alloca pointer.
It can tell you that the bottom bit is known zero (due to align 2) but it can't
tell you that bit 1 is known one. That's because the address could be an even
multiple of 2 rather than an odd multiple, eg it might be a multiple of 4. Thus
trying to use KnownOne is ineffective in the case of an alloca as it will never
have any bits set. Instead look explicitly for constant offsets from allocas
and globals.
llvm-svn: 164595
|
|
|
|
|
|
|
|
| |
This allows us to keep passing reduced masks to SimplifyDemandedBits, but
know about all the bits if SimplifyDemandedBits fails. This allows instcombine
to simplify cases like the one in the included testcase.
llvm-svn: 154011
|
|
|
|
|
|
| |
Add FIXMEs to places that are non-trivial to fix.
llvm-svn: 145661
|
|
|
|
|
|
|
| |
InstructionSimplify.cpp. Other fixups as needed.
Part of rdar://10500969
llvm-svn: 145559
|
|
|
|
| |
llvm-svn: 135375
|
|
|
|
| |
llvm-svn: 135040
|
|
|
|
|
|
| |
related tweaks to ExprMapKeyType.
llvm-svn: 129443
|
|
|
|
|
|
|
|
|
|
|
| |
with BasicAA's DecomposeGEPExpression, which recently began
using a TargetData. This fixes PR8968, though the testcase
is awkward to reduce.
Also, update several off GetUnderlyingObject's users
which happen to have a TargetData handy to pass it in.
llvm-svn: 124134
|
|
|
|
|
|
|
| |
function so that it can live in Analysis instead of
VMCore.
llvm-svn: 121885
|
|
|
|
| |
llvm-svn: 121727
|
|
|
|
| |
llvm-svn: 121514
|
|
|
|
|
|
|
| |
phi node itself if it occurs in an unreachable basic block. Protect
against this. Hopefully this will fix some more buildbots.
llvm-svn: 119493
|
|
|
|
|
|
|
|
| |
simplified to itself (this can only happen in unreachable blocks).
Change it to return null instead. Hopefully this will fix some
buildbot failures.
llvm-svn: 119490
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
class, uses DominatorTree which is an analysis. This change moves all of
the tricky hasConstantValue logic to SimplifyInstruction, and replaces it
with a very simple literal implementation. I already taught users of
hasConstantValue that need tricky stuff to use SimplifyInstruction instead.
I didn't update InlineFunction because the IR looks like it might be in a
funky state at the point it calls hasConstantValue, which makes calling
SimplifyInstruction dangerous since it can in theory do a lot of tricky
reasoning. This may be a pessimization, for example in the case where
all phi node operands are either undef or a fixed constant.
llvm-svn: 119459
|
|
|
|
| |
llvm-svn: 118822
|
|
|
|
|
|
| |
uint64_t, plus fixes for places I missed before.
llvm-svn: 116875
|
|
|
|
| |
llvm-svn: 116858
|
|
|
|
|
|
| |
for representing object sizes, for consistency with other parts of LLVM.
llvm-svn: 116831
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 116815
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 113073
|
|
|
|
|
|
|
| |
address-taken. This can occur normally, if the code which took the
address got DCEd.
llvm-svn: 111121
|
|
|
|
|
|
| |
had its address taken.
llvm-svn: 111058
|
|
|
|
| |
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
|
|
|
|
|
|
| |
are unknown.
llvm-svn: 110090
|
|
|
|
| |
llvm-svn: 110074
|
|
|
|
| |
llvm-svn: 109045
|
|
|
|
| |
llvm-svn: 108162
|
|
|
|
| |
llvm-svn: 107657
|
|
|
|
| |
llvm-svn: 107656
|
|
|
|
|
|
| |
an argument aliasing itself. Thanks Duncan!
llvm-svn: 105288
|
|
|
|
| |
llvm-svn: 105009
|
|
|
|
| |
llvm-svn: 104970
|
|
|
|
| |
llvm-svn: 104957
|
|
|
|
|
|
| |
reference the stack.
llvm-svn: 104951
|
|
|
|
|
|
|
| |
effective no-op constructs, to make it more effective on
unoptimized IR.
llvm-svn: 104950
|
|
|
|
| |
llvm-svn: 104936
|
|
|
|
|
|
|
| |
option from lintModule, which was an artifact from being
based on Verifier code.
llvm-svn: 104765
|
|
|
|
|
|
| |
and Write, and add a comment explaining this.
llvm-svn: 104756
|