This fixes clang generated blocks' variables' debug info.
Radar 9279956.

llvm-svn: 130373

llvm-svn: 130360

llvm-svn: 130343

give it a bit more responsibility. Also implement it for MachO.

If hacked to use cfi, 32 bit MachO will produce

.cfi_personality 155, L___gxx_personality_v0$non_lazy_ptr

and 64 bit will produce

.cfi_presonality ___gxx_personality_v0

The general idea is that .cfi_personality gets passed the final symbol. It is
up to codegen to produce it if using indirect representation (like 32 bit
MachO), but it is up to MC to decide which relocations to create.

llvm-svn: 130341

llvm-svn: 130339

Make the fast-isel code for literal 0.0 a bit shorter/faster, since 0.0 is common.  rdar://problem/9303592 .

llvm-svn: 130338

llvm-svn: 130337

llvm-svn: 130331

llvm-svn: 130326

successors) and use inverse depth first search to traverse the BBs. However
that doesn't work when the CFG has infinite loops. Simply do a linear
traversal of all BBs work just fine.

rdar://9344645

llvm-svn: 130324

We cannot rely on the <imp-def> operands added by LiveIntervals in all cases as
demonstrated by the test case.

llvm-svn: 130313

The number of blocks covered by a live range must be strictly decreasing when
splitting, otherwise we can't allow repeated splitting.

llvm-svn: 130249

more callee-saved registers and introduce copies. Only allows it if scheduling
a node above calls would end up lessen register pressure.

Call operands also has added ABI restrictions for register allocation, so be
extra careful with hoisting them above calls.

rdar://9329627

llvm-svn: 130245

llvm-svn: 130232

llvm-svn: 130231

This has two effects: 1. We never inflate to a larger register class than what
the sub-target can handle. 2. Completely unconstrained virtual registers get the
largest possible register class.

llvm-svn: 130229

llvm-svn: 130205

symbols.  For example, don't emit:
        .comm   _i,4,2                  ## @i
                                        ## @i

instead emit:
        .comm   _i,4,2                  ## @i

llvm-svn: 130192

llvm-svn: 130190

Remove previous DwarfCFI hack.

llvm-svn: 130187

Let dwarf writer allocate extra space in the debug location expression. This space, if requested, will be used for complex addresses of the Blocks' variables.

llvm-svn: 130178

llvm-svn: 130171

s/addVariableAddress/addFrameVariableAddress/g

llvm-svn: 130170

Observed this while reading code, so I do not have a test case handy here.

llvm-svn: 130167

A dbg.declare may not be in entry block, even if it is referring to an incoming argument. However, It is appropriate to emit DBG_VALUE referring to this incoming argument in entry block in MachineFunction.

llvm-svn: 130129

llvm-svn: 130116

Fixes PR9787.

llvm-svn: 130115

llvm-svn: 130095

llvm-svn: 130068

llvm-svn: 130033

llvm-svn: 130028

Sometimes it is better to split per block, and we missed those cases.

llvm-svn: 130025

fix bugs exposed by the gcc dejagnu testsuite:
1. The load may actually be used by a dead instruction, which
   would cause an assert.
2. The load may not be used by the current chain of instructions,
   and we could move it past a side-effecting instruction. Change
   how we process uses to define the problem away.

llvm-svn: 130018

On x86 this allows to fold a load into the cmp, greatly reducing register pressure.
  movzbl	(%rdi), %eax
  cmpl	$47, %eax
->
  cmpb	$47, (%rdi)

This shaves 8k off gcc.o on i386. I'll leave applying the patch in README.txt to Chris :)

llvm-svn: 130005

llvm-svn: 130004

llvm-svn: 129970

An exception is thrown via a call to _cxa_throw, which we don't expect to
return. Therefore, the "true" part of the invoke goes to a BB that has
'unreachable' as its only instruction. This is lowered into an empty MachineBB.
The landing pad for this invoke, however, is directly after the "true" MBB.
When the empty MBB is removed, the landing pad is directly below the BB with the
invoke call. The unconditional branch is removed and then the two blocks are
merged together.

The testcase is too big for a regression test.
<rdar://problem/9305728>

llvm-svn: 129965

llvm-svn: 129938

llvm-svn: 129928

These intervals are allocatable immediately after splitting, but they may be
evicted because of later splitting. This is rare, but when it happens they
should be split again.

The remainder intervals that cannot be allocated after splitting still move
directly to spilling.

SplitEditor::finish can optionally provide a mapping from new live intervals
back to the original interval indexes returned by openIntv().

Each original interval index can map to multiple new intervals after connected
components have been separated. Dead code elimination may also add existing
intervals to the list.

The reverse mapping allows the SplitEditor client to treat the new intervals
differently depending on the split region they came from.

llvm-svn: 129925