When local live range splitting creates a live range with the same
number of instructions as the old range, mark it as RS_Local. When such
a range is seen again, require that it be split in a way that reduces
the number of instructions. That guarantees we are making progress while
still being able to perform 3 -> 2+3 splits as required by PR10070.

This also means that the PrevSlot map is no longer needed. This was also
used to estimate new spill weights, but that is no longer necessary
after slotIndexes::insertMachineInstrInMaps() got the extra Late
insertion argument.

llvm-svn: 132697

Only target-dependent hints require callbacks. The RCI allocation order
has CSR aliases last according to their order of appearance in the
getCalleeSavedRegs list. This can depend on the calling convention.

This way, AllocationOrder::next doesn't have to check for reserved
registers, and CSRs are always allocated last, even with weird calling
conventions.

llvm-svn: 132690

legalize SDNodes such as BUILD_VECTOR, EXTRACT_VECTOR_ELT, etc.

llvm-svn: 132689

llvm-svn: 132681

The order of registers returned by getCalleeSavedRegs is used to lay out
the fixed stack slots for CSRs. Some targets like their CSRs used from
one end, and some targets want them used from the other end.

When computing an allocation order, simply preserve the relative
ordering of CSRs that the target specifies in its allocation order.
Reordering CSRs would break some targets, ARM in particular.

We still place volatiles before the CSRs, providing slightly better
results with different calling conventions.

llvm-svn: 132680

llvm-svn: 132676

llvm-svn: 132668

TypeLegalizer: Add support for passing of vector-promoted types in registers (copyFromParts/copyToParts).

llvm-svn: 132649

(only happens when using the -promote-elements option).

The correct legalization order is to first try to promote element. Next, we try
to widen vectors.

llvm-svn: 132648

of reserved registers.

Use RegisterClassInfo in RABasic as well. This slightly changes som
allocation orders because RegisterClassInfo puts CSR aliases last.

llvm-svn: 132581

Previously, these aliases would be ordered alphabetically. (BH, BL)

Print out the computed allocation orders.

llvm-svn: 132580

llvm-svn: 132559

When compiling a program with lots of small functions like
483.xalancbmk, this makes RAFast 11% faster.

Add some comments to clarify the difference between unallocatable and
reserved registers. It's quite subtle.

The fast register allocator depends on EFLAGS' not being allocatable on
x86. That way it can completely avoid tracking liveness, and it won't
mind when there are multiple uses of a single def.

llvm-svn: 132514

Part of rdar://9119939

llvm-svn: 132510

Some register classes are only used for instruction operand constraints.
They should never be used for virtual registers. Previously, those
register classes were given an empty allocation order, but now you can
say 'let isAllocatable=0' in the register class definition.

TableGen calculates if a register is part of any allocatable register
class, and makes that information available in TargetRegisterDesc::inAllocatableClass.

The goal here is to eliminate use cases for overriding allocation_order_*
methods.

llvm-svn: 132508

I was confused whether new uint8_t[] would zero-initialize the returned
array, and it seems that so is gcc-4.0.

This should fix the test failures on darwin 9.

llvm-svn: 132500

llvm-svn: 132488

llvm-svn: 132487

During post RA scheduling, do not try to chase reg defs. to preserve DBG_VALUEs. This approach has several downsides, for example, it does not work when dbg value is a constant integer, it does not work if reg is defined more than once, it places end of debug value range markers in the wrong place. It even causes misleading incorrect debug info when duplicate DBG_VALUE instructions point to same reg def. 

Instead, use simpler approach and let DBG_VALUE follow its predecessor instruction. After live debug value analysis pass, all DBG_VALUE instruction are placed at the right place. Thanks Jakob for the hint!

llvm-svn: 132483

llvm-svn: 132479

This saves two virtual function calls and an Allocatable BitVector test,
making RAFast run 2% faster.

llvm-svn: 132471

Found by valgrind.

llvm-svn: 132457

llvm-svn: 132456

No functional change.

llvm-svn: 132455

register classes.

It provides information for each register class that cannot be
determined statically, like:

- The number of allocatable registers in a class after filtering out the
  reserved and invalid registers.

- The preferred allocation order with registers that overlap callee-saved
  registers last.

- The last callee-saved register that overlaps a given physical register.

This information usually doesn't change between functions, so it is
reused for compiling multiple functions when possible.  The many
possible combinations of reserved and callee saves registers makes it
unfeasible to compute this information statically in TableGen.

Use RegisterClassInfo to count available registers in various heuristics
in SimpleRegisterCoalescing, making the pass run 4% faster.

llvm-svn: 132450

llvm-svn: 132433

llvm-svn: 132427

llvm-svn: 132424

types if the vector type is legal.

Fixes rdar://9306086

llvm-svn: 132420

the TargetLowering enum.

llvm-svn: 132418

This commit caused regressions in i386 flops-[568], matrix, salsa20,
256.bzip2, and enc-md5.

llvm-svn: 132413

rdar://problem/5660695

llvm-svn: 132411

llvm-svn: 132396

This patch is another step in the direction of adding vector select. In this
patch we add a flag to enable a new type legalization decision - to promote
integer elements in vectors. Currently, the rest of the codegen does not support
this kind of legalization.  This flag will be removed when the transition is
complete.

llvm-svn: 132394

For targets with no itinerary (x86) it is a nop by default. For
targets with issue width already expressed in the itinerary (ARM) it
bypasses a scoreboard check but otherwise does not affect the
schedule. It does make the code more consistent and complete and
allows new targets to specify their issue width in an arbitrary way.

llvm-svn: 132385

turns out that it could cause an infinite loop in some situations. If this code
is triggered and it converts a cleanup into a catchall, but that cleanup was in
already in a cleanup, then the _Unwind_SjLj_Resume could infinite loop. I.e.,
the code doesn't consume the exception object and passes it on to
_Unwind_SjLj_Resume. But _USjLjR expects it to be consumed (since it's landing
at a catchall instead of a cleanup). So it uses the values that are presently
there, which are the values that tell it to jump to the fake landing pad.
<rdar://problem/9508402>

llvm-svn: 132381

llvm-svn: 132377

llvm-svn: 132373

llvm-svn: 132371

When assigned ranges are evicted, they are put in the RS_Evicted stage and are
not allowed to evict anything else. That prevents looping automatically.

When evicting ranges just to get a cheaper register, use only spill weights to
find the possible candidates. Avoid breaking hints for this purpose, it is not
worth it.

Start implementing more complex eviction heuristics, guarded by the temporary
-complex-eviction flag. The initial version permits a heavier range to be
evicted if it doesn't have any uses where the evicting range is live. This makes
it a good candidate for live ranfge splitting.

llvm-svn: 132358