llvm-svn: 130876

This test fails on ARM. The test shouldn't explicitly specify alignment (and alignment 4 is wrong) and requires hard-float.

llvm-svn: 130875

If builder is initialized using an instruction as insertion point, then use the instruction's debug location as current debug location.

llvm-svn: 130874

llvm-svn: 130869

llvm-svn: 130867

Teach MachineCSE how to do simple cross-block CSE involving physregs.  This allows, for example, eliminating duplicate cmpl's on x86. Part of rdar://problem/8259436 .

llvm-svn: 130862

llvm-svn: 130860

llvm-svn: 130859

These tests all follow the same pattern:

	mov	r2, r0
	movs	r0, #0
	$CMP	r2, r1
	it	eq
	moveq	r0, #1
	bx	lr

The first 'mov' can be eliminated by rematerializing 'movs r0, #0' below the
test instruction:

	$CMP	r0, r1
	mov.w	r0, #0
	it	eq
	moveq	r0, #1
	bx	lr

So far, only physreg coalescing can do that. The register allocators won't yet
split live ranges just to eliminate copies. They can learn, but this particular
problem is not likely to show up in real code. It only appears because r0 is
used for both the function argument and return value.

llvm-svn: 130858

llvm-svn: 130857

llvm-svn: 130856

llvm-svn: 130855

llvm-svn: 130854

llvm-svn: 130850

llvm-svn: 130849

Prevent instructions using $gp from being placed between a jalr and the instruction that restores the clobbered $gp.

llvm-svn: 130847

it is both inefficient and unexpected by dwarfdump. Change to
a DW_FORM_data4.

While in here, change the predicate name to reflect that the position
is not really absolute (it is an offset), just that the linker needs a
relocation.

llvm-svn: 130846

Physreg joining is still on by default, but I will turn it off shortly.

llvm-svn: 130844

Tighten up check for empty (i.e. no meaningful debug info) module. This fixes dwarf-die2.c test case from gcc test suite.

llvm-svn: 130842

but according to my super-optimizer there are only two missed simplifications
of -instsimplify kind when compiling bzip2, and this is one of them.  It amuses
me to have bzip2 be perfectly optimized as far as instsimplify goes!

llvm-svn: 130840

frontend, if applicable.

llvm-svn: 130835

llvm-svn: 130834

llvm-svn: 130831

This adds functionality to remove size/zero extension during indvars
without generating a canonical IV and rewriting all IV users. It's
disabled by default so should have no effect on codegen. Work in progress.

llvm-svn: 130829

not, I'll just add them here and be done with it.

llvm-svn: 130819

llvm-svn: 130818

The basic allocator is really bad about hinting, so it doesn't eliminate all
copies when physreg joining is disabled.

llvm-svn: 130817

llvm-svn: 130816

llvm-svn: 130815

coalescing.

llvm-svn: 130814

llvm-svn: 130812

LiveVariables doesn't understand that clobbering D0 and D1 completely overwrites
Q0, so if Q0 is live-in to a function, its live range will extend beyond a
function call that only clobbers D0 and D1. This shows up in the
ARM/2009-11-01-NeonMoves test case.

LiveVariables should probably implement the much stricter rules for physreg
liveness that RAFast imposes - a physreg is killed by the first use of any
alias.

llvm-svn: 130801

llvm-svn: 130800

Only create a canonical IV for backedge taken count if it will
actually be used by LinearFunctionTestReplace. And some related
cleanup, preparing to reduce dependence on canonical IVs.
No significant effect on x86 or arm in the test-suite.

llvm-svn: 130799

Even if the subprogram is going to use AT_specification, emit DW_AT_MIPS_linkage_name. This helps gdb and fixes var-path-expr.exp regression reported by gdb testsuite.

llvm-svn: 130794

(and should thus never be done).
 - Should fix a crash on win32.

llvm-svn: 130793

<rdar://problem/8460511>

llvm-svn: 130791

Register coalescing can sometimes create live ranges that end in the middle of a
basic block without any killing instruction. When SplitKit detects this, it will
repair the live range by shrinking it to its uses.

Live range splitting also needs to know about this. When the range shrinks so
much that it becomes allocatable, live range splitting fails because it can't
find a good split point. It is paranoid about making progress, so an allocatable
range is considered an error.

The coalescer should really not be creating these bad live ranges. They appear
when coalescing dead copies.

llvm-svn: 130787

max(a,b) >= a -> true.  According to my super-optimizer, these are
by far the most common simplifications (of the -instsimplify kind)
that occur in the testsuite and aren't caught by -std-compile-opts.

llvm-svn: 130780

llvm-svn: 130779