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

of conservatively choosing MayAlias.

llvm-svn: 132579

llvm-svn: 132578

llvm-svn: 132575

addressing mode problem mentioned in r132559.

Backend part of rdar://9037836 and part of rdar://9119939

llvm-svn: 132561

llvm-svn: 132559

llvm-svn: 132558

A typedef's context is not the same as type's context. It is the context of typedef decl itself. Use extra parameter to communicate this to DIBuilder.

llvm-svn: 132556

llvm-svn: 132555

- Check for MTCTR8 in addition to MTCTR when looking up a hazard.

- When lowering an indirect call use CTR8 when targeting 64bit.

- Introduce BCTR8 that uses CTR8 and use it on 64bit when expanding ISD::BRIND.

The last change fixes PR8487. With those changes, we are able to compile a
running "ls" and "sh" on FreeBSD/PowerPC64.

llvm-svn: 132552

integers with high 32 bits being zero.

llvm-svn: 132538

llvm-svn: 132537

which edge to split by pred/succ pair, which means that we can end up splitting
the wrong edge (by case value) in the switch statement entirely. Fixes PR10031!

llvm-svn: 132535

llvm-svn: 132533

the handler's data area is similar to a DWARF-format LSDA. (It is, in fact,
a 32-bit pointer to the personality routine followed by the DWARF LSDA.)

llvm-svn: 132532

documentation. This should now reflect the current state of LLVM Makefiles.

llvm-svn: 132527

llvm-svn: 132526

Add ARM fast-isel support for materializing the address of a global in cases where the global uses an indirect symbol.

rdar://9431157

llvm-svn: 132522

Added asserts whenever attempting to use a potentially
uninitialized pass. This helps people trying to develop a new pass and
people trying to understand the bug reports filed by the former people.

llvm-svn: 132520

llvm-svn: 132519

llvm-svn: 132516

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

allocation orders.

llvm-svn: 132509

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

llvm-svn: 132505

llvm-svn: 132504

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: 132495

llvm-svn: 132494

llvm-svn: 132488

llvm-svn: 132487

llvm-svn: 132486

PR10067: Add missing safety check to call return transformation in MemCpyOpt::processStore.  If something accesses the dest of the "copy" between the call and the copy, the performCallSlotOptzn transformation is not valid.

llvm-svn: 132485

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: 132482

llvm-svn: 132479

llvm-svn: 132477

Testcase will come when we use it.

Part of rdar://9119939

llvm-svn: 132476