llvm-svn: 135375

consistently.

llvm-svn: 131803

Luis Felipe Strano Moraes!

llvm-svn: 129558

instructions.

llvm-svn: 123973

llvm-svn: 123573

there should be a better way to do this.  PR 8679.

llvm-svn: 120457

Get rid of static constructors for pass registration.  Instead, every pass 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: 115996

llvm-svn: 111344

before it rewrites the code, we need to use that in the post-rewrite pass.

llvm-svn: 110962

llvm-svn: 110460

llvm-svn: 110410

ID member as the sole unique type identifier.  Clean up APIs related to this change.

llvm-svn: 110396

llvm-svn: 109687

llvm-svn: 109045

llvm-svn: 102358

forced constant is changed to a constant, we would end
up adding the instruction to the wrong worklist, 
preventing it from being properly revisited.  This fixes
rdar://7832370

llvm-svn: 100837

undefs in branches/switches, we have two cases: a branch on a literal
undef or a branch on a symbolic value which is undef.  If we have a
literal undef, the code was correct: forcing it to a constant is the
right thing to do.

If we have a branch on a symbolic value that is undef, we should force
the symbolic value to a constant, which then makes the successor block
live.  Forcing the condition of the branch to being a constant isn't 
safe if later paths become live and the value becomes overdefined.  This
is the case that 'forcedconstant' is designed to handle, so just use it.

This fixes rdar://7765019 but there is no good testcase for this, the
one I have is too insane to be useful in the future.

llvm-svn: 100478

is necessary. Inherits from new templated baseclass CallSiteBase<>
which is highly customizable. Base CallSite on it too, in a configuration
that allows full mutation.
Adapt some call sites in analyses to employ ImmutableCallSite.

llvm-svn: 100100

llvm-svn: 99564

I have audited all getOperandNo calls now, fixing
hidden assumptions. CallSite related uglyness will
be eliminated successively.

Note this patch has a long and griveous history,
for all the back-and-forths have a look at
CallSite.h's log.

llvm-svn: 99399

llvm-svn: 99395

llvm-svn: 97313

of a subtle interation in a loop operating in densemap order.

llvm-svn: 97288

and T->isPointerTy().  Convert most instances of the first form to the second form.
Requested by Chris.

llvm-svn: 96344

llvm-svn: 92612

adjacent uses of a dead basic block from the same user. This fixes PR5596.

llvm-svn: 89658

blockaddress users. This fixes PR5569.

llvm-svn: 89483

tracked down by Stephan Reiter!

llvm-svn: 86726

llvm-svn: 86133

resizes in IPSCCP.  This fixes PR5394.

llvm-svn: 86036

more aggressive an correct.  This survives building llvm in 64-bit
mode with optimizations and the built llvm passes make check.

llvm-svn: 85973

llvm-svn: 85937

functions that don't have local linkage.  Basically, we need to be more
careful about propagating argument information to functions whose results
we aren't tracking.  This fixes a miscompilation of 
LLVMCConfigurationEmitter.cpp when built with an llvm-gcc that has ipsccp
enabled.

llvm-svn: 85923

to follow.

llvm-svn: 85903

llvm-svn: 85858

std::map to DenseMap, exposed on release llvm-gcc bootstrap.

llvm-svn: 85840

llvm-svn: 85818

disable it until I can fix it.

llvm-svn: 85810

function to calls of that function, regardless of whether it has local
linkage or has its address taken.  Not escaping should only affect 
whether we make an aggressive assumption about the arguments to a 
function, not whether we can track the result of it.

llvm-svn: 85795