llvm-svn: 137872

One way to exit the loop is through an unwind edge. However, that may involve
splitting the critical edge of the landing pad, which is non-trivial. Prevent
the transformation from rewriting the landing pad exit loop block.

llvm-svn: 137871

so requires more care than this generic algorithm should handle.

llvm-svn: 137866

instruction should be marked as potentially reading and/or writing memory.

llvm-svn: 137863

Silly mistake from r137777; restore significant isStructTy() checks.  While here, be a bit more defensive
with unknown instructions.

Fixes PR10687.

llvm-svn: 137836

making random bad assumptions about instructions which are not explicitly listed.  

Includes fix for rdar://9956541, a version of "undef ^ undef should return
0 because it's easier than arguing with users".

llvm-svn: 137777

Minor bug in SCCP found by inspection.  (I don't think it's possible to hit this with a normal pass pipeline, but fixing for completeness.)

llvm-svn: 137755

check for a LandingPadInst.

llvm-svn: 137745

llvm-svn: 137743

Add a mechanism for optimisation plugins to register passes that all front ends can use without needing to be aware of the plugin (or the plugin be aware of the front end).

Before 3.0, I'd like to add a mechanism for automatically loading a set of plugins from a config file.  API suggestions welcome...

llvm-svn: 137717

llvm-svn: 137712

llvm-svn: 137702

to be wrong (or at least somewhat suspect).  Leave a FIXME for Bill.

llvm-svn: 137694

llvm-svn: 137693

This commit includes a mention of the landingpad instruction, but it's not
changing the behavior around it.  I think the current behavior is correct,
though.  Bill, can you double-check that?

llvm-svn: 137691

llvm-svn: 137690

llvm-svn: 137679

llvm-svn: 137672

llvm-svn: 137667

llvm-svn: 137664

write to memory.) Marking it as such makes some checks for immobility go away.

llvm-svn: 137655

llvm-svn: 137654

llvm-svn: 137648

llvm-svn: 137642

llvm-svn: 137629

llvm-svn: 137627

llvm-svn: 137626

This builds off of the current scheme, but instead of llvm.eh.exception and
llvm.eh.selector, it uses the landingpad instruction. And instead of
llvm.eh.resume, it uses the resume instruction.

Because of the invariants in the landing pad instruction, a lot of code that's
currently needed to find the appropriate intrinsic calls for an invoke
instruction won't be needed once we go to the new EH scheme. The "FIXME"s tell
us what to remove after we switch.

llvm-svn: 137576

llvm-svn: 137575

llvm-svn: 137572

when combining add and sub instructions. Patch by Pranav Bhandarkar!

llvm-svn: 137570

This implements the 'landingpad' instruction. It's used to indicate that a basic
block is a landing pad. There are several restrictions on its use (see
LangRef.html for more detail). These restrictions allow the exception handling
code to gather the information it needs in a much more sane way.

This patch has the definition, implementation, C interface, parsing, and bitcode
support in it.

llvm-svn: 137501

llvm-svn: 137480

when building with assertions disabled.

llvm-svn: 137460

is returned through a bitcast.

llvm-svn: 137402

the retains and releases all use the same SSA pointer value.

Also, don't let CFG hazards disrupt nested retain+release pair
optimizations.

llvm-svn: 137399

rather than plain postorder, so that CFG constructs like single-exit loops
are reliably visited in a sensible order.

llvm-svn: 137398

SCEV unrolling can unroll loops with arbitrary induction variables. It
is a prerequisite for -disable-iv-rewrite performance. It is also
easily handles loops of arbitrary structure including multiple exits
and is generally more robust.

This is under a temporary option to avoid affecting default
behavior for the next couple of weeks. It is needed so that I can
checkin unit tests for updateUnloop.

llvm-svn: 137384

llvm-svn: 137352

Distinguish between two copies of one inlined variable. Take 2.

llvm-svn: 137253