llvm-svn: 130248

work-in-progress that is not progressing, and it has issues.

llvm-svn: 130247

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

This test should be in MC. It breaks with changes to scheduling / register allocation so it's being removed.

llvm-svn: 130243

1. Only run the early (in the module pass pipe) instcombine/simplifycfg
   if the "unit at a time" passes they are cleaning up after runs.

2. Move the "clean up after the unroller" pass to the very end of the
   function-level pass pipeline.  Loop unroll uses instsimplify now,
   so it doesn't create a ton of trash.  Moving instcombine later allows
   it to clean up after opportunities are exposed by GVN, DSE, etc.

3. Introduce some phase ordering tests for things that are specifically
   intended to be simplified by the full optimizer as a whole.

This resolves PR2338, and is progress towards PR6627, which will be 
generating code that looks similar to test2.

llvm-svn: 130241

when X has multiple uses.  This is useful for exposing secondary optimizations,
but the X86 backend isn't ready for this when X has a single use.  For example,
this can disable load folding.

This is inching towards resolving PR6627.

llvm-svn: 130238

llvm-svn: 130237

predicate that matches if the subexpr has a single use.

llvm-svn: 130235

rdar://9326019

llvm-svn: 130234

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

The hook will be used by the register allocator when recomputing register
classes after removing constraints.

Thumb1 code doesn't allow anything larger than tGPR, and x86 needs to ensure
that the spill size doesn't change.

llvm-svn: 130228

llvm-svn: 130226

This worked untill now because stars are aligned (i.e. num of complex address elments are always 0 or 2+ and when it is 2+ at least two elements are access together)

llvm-svn: 130225

translation fails.  We were bailing out in some cases that would
cause us to miss GVN'ing some non-local cases away.

llvm-svn: 130206

llvm-svn: 130205

llvm-svn: 130199

llvm-svn: 130198

llvm-svn: 130193

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

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

llvm-svn: 130192

llvm-svn: 130191

llvm-svn: 130190

Remove previous DwarfCFI hack.

llvm-svn: 130187

Add support for switch and indirectbr edges. This works by densely numbering
all blocks which have such terminators, and then separately numbering the
possible successors. The predecessors write down a number, the successor knows
its own number (as a ConstantInt) and sends that and the pointer to the number
the predecessor wrote down to the runtime, who looks up the counter in a
per-function table.

Coverage data should now be functional, but I haven't tested it on anything
other than my 2-file synthetic test program for coverage.

llvm-svn: 130186

llvm-svn: 130181

return it as a clobber.  This allows GVN to do smart things.

Enhance GVN to be smart about the case when a small load is clobbered
by a larger overlapping load.  In this case, forward the value.  This
allows us to compile stuff like this:

int test(void *P) {
  int tmp = *(unsigned int*)P;
  return tmp+*((unsigned char*)P+1);
}

into:

_test:                                  ## @test
	movl	(%rdi), %ecx
	movzbl	%ch, %eax
	addl	%ecx, %eax
	ret

which has one load.  We already handled the case where the smaller
load was from a must-aliased base pointer.

llvm-svn: 130180

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

llvm-svn: 130166

llvm-svn: 130165

llvm-svn: 130160

llvm-svn: 130153

patch by Johannes Schaub!

llvm-svn: 130151

llvm-svn: 130137

llvm-svn: 130131

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

lit needs a linter ...

llvm-svn: 130126