Don't crash when we encounter one of these.

llvm-svn: 51915

llvm-svn: 51890

llvm-svn: 51789

Since LCSSA switched over to DenseMap, we have to be more careful to avoid iterator invalidation.  Fixes PR2385.

llvm-svn: 51777

the section or the visibility from one global
value to another: copyAttributesFrom.  This is
particularly useful for duplicating functions:
previously this was done by explicitly copying
each attribute in turn at each place where a
new function was created out of an old one, with
the result that obscure attributes were regularly
forgotten (like the collector or the section).
Hopefully now everything is uniform and nothing
is forgotten.

llvm-svn: 51567

llvm-svn: 51565

use it instead of duplicating its functionality.

llvm-svn: 51499

The SimplifyCFG pass looks at basic blocks that contain only phi nodes,
followed by an unconditional branch. In a lot of cases, such a block (BB) can
be merged into their successor (Succ).

This merging is performed by TryToSimplifyUncondBranchFromEmptyBlock. It does
this by taking all phi nodes in the succesor block Succ and expanding them to
include the predecessors of BB. Furthermore, any phi nodes in BB are moved to
Succ and expanded to include the predecessors of Succ as well.

Before attempting this merge, CanPropagatePredecessorsForPHIs checks to see if
all phi nodes can be properly merged. All functional changes are made to
this function, only comments were updated in
TryToSimplifyUncondBranchFromEmptyBlock.

In the original code, CanPropagatePredecessorsForPHIs looks quite convoluted
and more like stack of checks added to handle different kinds of situations
than a comprehensive check. In particular the first check in the function did
some value checking for the case that BB and Succ have a common predecessor,
while the last check in the function simply rejected all cases where BB and
Succ have a common predecessor. The first check was still useful in the case
that BB did not contain any phi nodes at all, though, so it was not completely
useless.

Now, CanPropagatePredecessorsForPHIs is restructured to to look a lot more
similar to the code that actually performs the merge. Both functions now look
at the same phi nodes in about the same order.  Any conflicts (phi nodes with
different values for the same source) that could arise from merging or moving
phi nodes are detected. If no conflicts are found, the merge can happen.

Apart from only restructuring the checks, two main changes in functionality
happened.

Firstly, the old code rejected blocks with common predecessors in most cases.
The new code performs some extra checks so common predecessors can be handled
in a lot of cases. Wherever common predecessors still pose problems, the
blocks are left untouched.

Secondly, the old code rejected the merge when values (phi nodes) from BB were
used in any other place than Succ. However, it does not seem that there is any
situation that would require this check. Even more, this can be proven.

Consider that BB is a block containing of a single phi node "%a" and a branch
to Succ. Now, since the definition of %a will dominate all of its uses, BB
will dominate all blocks that use %a. Furthermore, since the branch from BB to
Succ is unconditional, Succ will also dominate all uses of %a.

Now, assume that one predecessor of Succ is not dominated by BB (and thus not
dominated by Succ). Since at least one use of %a (but in reality all of them)
is reachable from Succ, you could end up at a use of %a without passing
through it's definition in BB (by coming from X through Succ). This is a
contradiction, meaning that our original assumption is wrong. Thus, all
predecessors of Succ must also be dominated by BB (and thus also by Succ).

This means that moving the phi node %a from BB to Succ does not pose any
problems when the two blocks are merged, and any use checks are not needed.

llvm-svn: 51478

API change for {BinaryOperator|CmpInst|CastInst}::create*() --> Create. Legacy interfaces will be in place for some time.  (Merge from use-diet branch.)

llvm-svn: 51200

Fix a bunch of 80col violations that arose from the Create API change. Tweak makefile targets to find these better.

llvm-svn: 51143

Patch by Matthijs Kooijman!

llvm-svn: 51083

address of the PassInfo directly instead of calling getPassInfo.
This eliminates a bunch of dynamic initializations of static data.

Also, fold RegisterPassBase into PassInfo, make a bunch of its
data members const, and rearrange some code to initialize data
members in constructors instead of using setter member functions.

llvm-svn: 51022

several things that were neither in an anonymous namespace nor static
but not intended to be global.

llvm-svn: 51017

llvm-svn: 50696

llvm-svn: 50695

llvm-svn: 50604

multiple return values.

Bill, please pull this into Tak.

llvm-svn: 50332

llvm-svn: 50271

r48047 r48084 r48085 r48086 r48088 r48096 r48099 r48109 and r48123.

llvm-svn: 50265

ConstantExpression GEPs pointing into constant globals.

llvm-svn: 50256

llvm-svn: 50222

Fix said code to handle merging return instructions together correctly
when handling multiple return values.

llvm-svn: 50199

llvm-svn: 50179

as a global helper function.  At the same type, switch it from taking
a vector of predecessors to an arbitrary sequential input.  This allows
us to switch LoopSimplify to use a SmallVector for various temporary
vectors that it passed into SplitBlockPredecessors.

llvm-svn: 50020

nodes, removing a hack.

llvm-svn: 50019

instead of doing it after every call.

llvm-svn: 50018

llvm-svn: 50015

llvm-svn: 50014

llvm-svn: 49838

wee problem in Xcode 2.[45]/gcc 4.0.1.

llvm-svn: 49831

VisualStudio project files updated.  #include <algorithm> added to make VisualStudio happy.  Also had to undefine setjmp because of #include <csetjmp> turning setjmp into _setjmp in VisualStudio.

llvm-svn: 49743

llvm-svn: 49657

which is significantly more efficient.

llvm-svn: 49614

llvm-svn: 49367

needs to be fixed here - a previous commit made sure
that intrinsics always get the right attributes.
So remove no-longer needed code, and while there use
Intrinsic::getDeclaration rather than getOrInsertFunction. 

llvm-svn: 49337

intrinsics.  Fix up the argument type (should
be i8*, was an array*).

llvm-svn: 49336

nounwind.  When such calls are inlined into something
else that is invoked, they were getting changed to invokes,
which is badness.

llvm-svn: 49299

Specifically, introduction of XXX::Create methods
for Users that have a potentially variable number of
Uses.

llvm-svn: 49277

2. Do not use # of basic blocks as part of the cost computation since it doesn't really figure into function size.
3. More aggressively inline function with vector code.

llvm-svn: 49061

llvm-svn: 49046