solution.  The only reason these don't fire with gcc-4.2 is that gcc turns off
part of -Wsign-compare in C++ on accident.

llvm-svn: 100581

llvm-svn: 100578

There is probably a more elegant way to do this.

llvm-svn: 100573

Radar 7770501.

llvm-svn: 100568

When a frame pointer is not otherwise required, and dynamic stack alignment
is necessary solely due to the spilling of a register with larger alignment
requirements than the default stack alignment, the frame pointer can be both
used as a general purpose register and a frame pointer. That goes poorly, for
obvious reasons. This patch brings back a bit of old logic for identifying
the use of such registers and conservatively reserves the frame pointer
during register allocation in such cases.

For now, implement for X86 only since it's 32-bit linux which is hitting this,
and we want a targeted fix for 2.7. As a follow-on, this will be expanded
to handle other targets, as theoretically the problem could arise elsewhere
as well.

llvm-svn: 100559

This fixes the Bullet regression on i386/nocona.

llvm-svn: 100553

Operand 2 on a load instruction does not have to be a RegisterSDNode for this to
work.

llvm-svn: 100497

llvm-svn: 100480

llvm-svn: 100466

isn't well specified.  ARM really needs to have its instprinter
finished at some point.

llvm-svn: 100439

with spaces in them.  Sym->getName()  !=   OS << *Sym

llvm-svn: 100434

llvm-svn: 100423

llvm-svn: 100416

llvm-svn: 100415

llvm-svn: 100412

llvm-svn: 100404

  uint32_t insn;
  MemoryObject.readBytes(Address, 4, (uint8_t*)&insn, NULL)

to read 4 bytes of memory contents into a 32-bit uint variable.  This leaves the
interpretation of byte order up to the host machine and causes PPC test cases of
arm-tests, neon-tests, and thumb-tests to fail.  Fixed to use a byte array for
reading the memory contents and shift the bytes into place for the 32-bit uint
variable in the ARM case and 16-bit halfword in the Thumb case.

llvm-svn: 100403

allowing xcore to use the normal runOnMachineFunction 
implementation.

llvm-svn: 100402

llvm-svn: 100399

When a target instruction wants to set target-specific flags, it should simply
set bits in the TSFlags bit vector defined in the Instruction TableGen class.

This works well because TableGen resolves member references late:

class I : Instruction {
  AddrMode AM = AddrModeNone;
  let TSFlags{3-0} = AM.Value;
}

let AM = AddrMode4 in
def ADD : I;

TSFlags gets the expected bits from AddrMode4 in this example.

llvm-svn: 100384

llvm-svn: 100381

llvm-svn: 100380

llvm-svn: 100379

Reverting 100265 to try to get buildbots green again. Lots of self-hosting buildbots started complaining since this commit. Also xfail ARM disassembly tests.

llvm-svn: 100378

llvm-svn: 100377

llvm-svn: 100376

which is really a property of the section being referenced.
Add a predicate to MCSection to replace it.

Yay for reduction in magic.

llvm-svn: 100367

llvm-svn: 100358

llvm-svn: 100357

Restrict bit mask operations to the DomainValue class. Rename methods for
clarity.

llvm-svn: 100353

llvm-svn: 100352

llvm-svn: 100342

enough to warrant caching in AsmPrinter, so remove it.

llvm-svn: 100336

llvm-svn: 100332

"asm printering" happens through MCStreamer.  This also 
Streamerizes PIC16 debug info, which escaped my attention.

This removes a leak from LLVMTargetMachine of the 'legacy'
output stream.

llvm-svn: 100327

llvm-svn: 100322

llvm-svn: 100321

llvm-svn: 100320

don't have mcstreamer support for yet.

llvm-svn: 100319

implementations to use EmitRawText instead of writing
directly to "O".

llvm-svn: 100318