so requires more care than this generic algorithm should handle.

llvm-svn: 137866

llvm-svn: 137743

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: 137654

llvm-svn: 137642

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: 137480

when building with assertions disabled.

llvm-svn: 137460

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

llvm-svn: 137253

Also, my apologies for spoiling the autocomplete on SimplifyInstructions.cpp. I couldn't think of a better filename.

llvm-svn: 137229

llvm-svn: 137203

SimplifyIndVar utility since it is required.

llvm-svn: 137202

llvm-svn: 137199

llvm-svn: 137198

based on ScalarEvolution without changing the induction variable phis.

This utility is the main tool of IndVarSimplifyPass, but the pass also
restructures induction variables in strange ways that are sensitive to
pass ordering. This provides a way for other loop passes to simplify
new uses of induction variables created during transformation. The
utility may be used by any pass that preserves ScalarEvolution. Soon
LoopUnroll will use it.

The net effect in this checkin is to cleanup the IndVarSimplify pass
by factoring out the SimplifyIndVar algorithm into a standalone utility.

llvm-svn: 137197

llvm-svn: 137195

These are not individual bug fixes. I had to rewrite a good chunk of
the unroller to make it sane. I think it was getting lucky on trivial
completely unrolled loops with no early exits. I included some fairly
simple unit tests for partial unrolling. I didn't do much stress
testing, so it may not be perfect, but should be usable now.

llvm-svn: 137190

LoopUnroll looks like it has some stale code. Remove it to prove my sanity and avoid further confusion.

llvm-svn: 137106

instead of a vector.

llvm-svn: 137099

The 'unwind' instruction was acting essentially as a placeholder, because it
would be replaced at the end of this function by a branch to the "unwind
handler". The 'unwind' instruction is going away, so use 'unreachable' instead,
which serves the same purpose as a placeholder.

llvm-svn: 137098

inlined variable, based on the discussion in PR10542.

This explodes the runtime of several passes down the pipeline due to
a large number of "copies" remaining live across a large function. This
only shows up with both debug and opt, but when it does it creates
a many-minute compile when self-hosting LLVM+Clang. There are several
other cases that show these types of regressions.

All of this is tracked in PR10542, and progress is being made on fixing
the issue. Once its addressed, the re-instated, but until then this
restores the performance for self-hosting and other opt+debug builds.

Devang, let me know if this causes any trouble, or impedes fixing it in
any way, and thanks for working on this!

llvm-svn: 136953

We need to map DebugLoc. It leads to Fuction * (through subprogram entry node) which should be appropriately mapped.

llvm-svn: 136910

to notify SCEV of a change. Add forgetLoop in a couple of those places.

llvm-svn: 136797

llvm-svn: 136795

llvm-svn: 136722

r136339, r136341, r136369, r136387, r136392, r136396, r136429, r136430, r136444,
r136445, r136446, r136253 pending review.

llvm-svn: 136556

specified in the same file that the library itself is created. This is
more idiomatic for CMake builds, and also allows us to correctly specify
dependencies that are missed due to bugs in the GenLibDeps perl script,
or change from compiler to compiler. On Linux, this returns CMake to
a place where it can relably rebuild several targets of LLVM.

I have tried not to change the dependencies from the ones in the current
auto-generated file. The only places I've really diverged are in places
where I was seeing link failures, and added a dependency. The goal of
this patch is not to start changing the dependencies, merely to move
them into the correct location, and an explicit form that we can control
and change when necessary.

This also removes a serialization point in the build because we don't
have to scan all the libraries before we begin building various tools.
We no longer have a step of the build that regenerates a file inside the
source tree. A few other associated cleanups fall out of this.

This isn't really finished yet though. After talking to dgregor he urged
switching to a single CMake macro to construct libraries with both
sources and dependencies in the arguments. Migrating from the two macros
to that style will be a follow-up patch.

Also, llvm-config is still generated with GenLibDeps.pl, which means it
still has slightly buggy dependencies. The internal CMake
'llvm-config-like' macro uses the correct explicitly specified
dependencies however. A future patch will switch llvm-config generation
(when using CMake) to be based on these deps as well.

This may well break Windows. I'm getting a machine set up now to dig
into any failures there. If anyone can chime in with problems they see
or ideas of how to solve them for Windows, much appreciated.

llvm-svn: 136433

llvm-svn: 136341

The new EH is more simple in many respects. Mainly, we don't have to worry about
the "llvm.eh.exception" and "llvm.eh.selector" calls being in weird places.

llvm-svn: 136339

landingpad.

llvm-svn: 136329

This takes the new 'resume' instruction and turns it into a direct jump to the
caller's landing pad code. The caller's landingpad instruction is merged with
the landingpad instructions of the callee. This is a bit rough and makes some
assumptions in how the code works. But it passes a simple test.

llvm-svn: 136313

llvm-svn: 136269

llvm-svn: 135988

llvm-svn: 135904

removes its dependence on canonical induction variables.

llvm-svn: 135829

llvm-svn: 135828

Clean up includes of llvm/Analysis/ConstantFolding.h so it's included where it's used and not included where it isn't.

llvm-svn: 135628