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

Patch by Ivan Krasin!

llvm-svn: 136921

llvm-svn: 136916

llvm-svn: 136915

llvm-svn: 136901

It is possible to have multiple DBG_VALUEs for the same variable:

32L TEST32rr %vreg0<kill>, %vreg0, %EFLAGS<imp-def>; GR32:%vreg0
    DBG_VALUE 2, 0, !"i"
    DBG_VALUE %noreg, %0, !"i"

When that happens, keep the last one instead of the first.

llvm-svn: 136842

This helps generate better code in functions with high register
pressure.

The previous version of compact region splitting caused regressions
because the regions were a bit too large. A stronger negative bias
applied in r136832 fixed this problem.

llvm-svn: 136836

Do not drop undef debug values. These are used as range termination marker by live debug variable pass.

llvm-svn: 136834

Apply twice the negative bias on transparent blocks when computing the
compact regions. This excludes loop backedges from the region when only
one of the loop blocks uses the register.

Previously, we would include the backedge in the region if the loop
preheader and the loop latch both used the register, but the loop header
didn't.

When both the header and latch blocks use the register, we still keep it
live on the backedge.

llvm-svn: 136832

lib/CodeGen/RegAllocGreedy.cpp:1176:18: warning: unused variable 'B' [-Wunused-variable]
    if (unsigned B = Cand.getBundles(BundleCand, BestCand)) {
                 ^
lib/CodeGen/RegAllocGreedy.cpp:1188:18: warning: unused variable 'B' [-Wunused-variable]
    if (unsigned B = Cand.getBundles(BundleCand, 0)) {
                 ^

llvm-svn: 136831

llvm-svn: 136828

llvm-svn: 136826

llvm-svn: 136816

New approach to r136737: insert the necessary fences for atomic ops in platform-independent code, since a bunch of platforms (ARM, Mips, PPC, Alpha are the relevant targets here) need to do essentially the same thing.

I think this completes the basic CodeGen for atomicrmw and cmpxchg.

llvm-svn: 136813

llvm-svn: 136802

llvm-svn: 136759

llvm-svn: 136742

This information is not used for anything yet.

llvm-svn: 136741

With a 'FirstDef' field right there, it is very confusing that FirstUse
refers to an instruction that may be a def.

llvm-svn: 136739

This is either an invalid SlotIndex, or valno->def for the first value
defined inside the block. PHI values are not counted as defined inside
the block.

The FirstDef field will be used when estimating the cost of spilling
around a block.

llvm-svn: 136736

llvm-svn: 136735

The PrefBoth constraint is used for blocks that ideally want a live-in
value both on the stack and in a register. This would be used by a block
that has a use before interference forces a spill.

Secondly, add the ChangesValue flag to BlockConstraint. This tells
SpillPlacement if a live-in value on the stack can be reused as a
live-out stack value for free. If the block redefines the virtual
register, a spill would be required for that.

This extra information will be used by SpillPlacement to more accurately
calculate spill costs when a value can exist both on the stack and in a
register.

The simplest example is a basic block that reads the virtual register,
but doesn't change its value. Spilling around such a block requires a
reload, but no spill in the block.

The spiller already knows this, but the spill placer doesn't. That can
sometimes lead to suboptimal regions.

llvm-svn: 136731

The testcase looks extremely fragile, so I'm adding an assertion which should catch any cases like this.

llvm-svn: 136711

llvm-svn: 136609

This adds the 'resume' instruction class, IR parsing, and bitcode reading and
writing. The 'resume' instruction resumes propagation of an existing (in-flight)
exception whose unwinding was interrupted with a 'landingpad' instruction (to be
added later).

llvm-svn: 136589

llvm-svn: 136584

While this generally helped x86-64, there was some large regressions
for i386.

llvm-svn: 136571

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

llvm-svn: 136556

The ARM target depends on CPSR liveness being tracked after register
allocation.

llvm-svn: 136548

This includes registers like EFLAGS and ST0-ST7. We don't check for
liveness issues in the verifier and scavenger because registers will
never be allocated from these classes.

While in SSA form, we do care about the liveness of unallocatable
unreserved registers. Liveness of EFLAGS and ST0 neds to be correct for
MachineDCE and MachineSinking.

llvm-svn: 136541

llvm-svn: 136535

This flag is true from isel to register allocation when the machine
function is required to be in SSA form.  The TwoAddressInstructionPass
and PHIElimination passes clear the flag.

The SSA flag wil be used by the machine code verifier to check for SSA
form, and eventually an assertion can enforce it in +Asserts builds.
This will catch the common target error of creating machine code with
multiple defs of a virtual register.

llvm-svn: 136532

llvm-svn: 136529

This helps generate better code in functions with high register
pressure.

llvm-svn: 136528

llvm-svn: 136506

lines. No functionality change.

llvm-svn: 136458

working on x86 (at least for trivial testcases); other architectures will
need more work so that they actually emit the appropriate instructions for
orderings stricter than 'monotonic'. (As far as I can tell, the ARM, PPC,
Mips, and Alpha backends need such changes.)

llvm-svn: 136457

With this, we can now compile a simple EH program.

llvm-svn: 136446

llvm-svn: 136445

llvm-svn: 136444