llvm-svn: 100480

undefs in branches/switches, we have two cases: a branch on a literal
undef or a branch on a symbolic value which is undef.  If we have a
literal undef, the code was correct: forcing it to a constant is the
right thing to do.

If we have a branch on a symbolic value that is undef, we should force
the symbolic value to a constant, which then makes the successor block
live.  Forcing the condition of the branch to being a constant isn't 
safe if later paths become live and the value becomes overdefined.  This
is the case that 'forcedconstant' is designed to handle, so just use it.

This fixes rdar://7765019 but there is no good testcase for this, the
one I have is too insane to be useful in the future.

llvm-svn: 100478

llvm-svn: 100468

llvm-svn: 100467

llvm-svn: 100466

llvm-svn: 100461

llvm-svn: 100459

PR6779

llvm-svn: 100457

llvm-svn: 100455

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

llvm-svn: 100439

llvm-svn: 100438

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

llvm-svn: 100434

llvm-svn: 100423

llvm-svn: 100419

instantiating some folding set stuff that GCC isn't, requiring 
some types to not be incomplete.

I don't know if clang is right or wrong, but unbreaking the
bot is goodness.  Here's the broken build:
http://google1.osuosl.org:8011/builders/clang-x86_64-darwin10-selfhost/builds/1813/steps/compile.llvm.stage2/logs/stdio

llvm-svn: 100418

llvm-svn: 100417

llvm-svn: 100416

llvm-svn: 100415

llvm-svn: 100414

llvm-svn: 100412

llvm-svn: 100410

llvm-svn: 100409

llvm-svn: 100408

llvm-svn: 100407

llvm-svn: 100406

instead of going through DwarfWriter.

llvm-svn: 100405

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

need it anymore, so don't addRequire it.

llvm-svn: 100400

llvm-svn: 100399

llvm-svn: 100386

llvm-svn: 100385

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

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