llvm-svn: 112742

r112728 did this for fast regalloc.

llvm-svn: 112741

llvm-svn: 112728

llvm-svn: 112726

if we schedule another LVI-using pass afterwards.

llvm-svn: 112722

llvm-svn: 112721

self host errors on clang-x86-64.

llvm-svn: 112719

on an producing weird link errors.  Patch by Yuri Gribov!

llvm-svn: 112714

llvm-svn: 112713

llvm-svn: 112712

the testcases should be merged.

llvm-svn: 112711

of a base class.

This makes it possible to unregister the file from FilesToRemove when
the file is done. Also, this eliminates the need for
formatted_tool_output_file.

llvm-svn: 112706

llvm-svn: 112705

landing pad into uses of registers rather than loads from a stack
slot.  Doesn't touch the 'orrible hack code - Bill needs to persuade
me harder :)

llvm-svn: 112702

then the SSAUpdator may access freed memory.  Instead, simply pass
in the type and name explicitly, which is all that was used anyway.

llvm-svn: 112699

on llvmdev: SRoA is introducing MMX datatypes like <1 x i64>,
which then cause random problems because the X86 backend is
producing mmx stuff without inserting proper emms calls.

In the short term, force off MMX datatypes.  In the long term,
the X86 backend should not select generic vector types to MMX
registers.  This is being worked on, but won't be done in time
for 2.8.  rdar://8380055

llvm-svn: 112696

Use movlps, movlpd, movss and movsd specific nodes instead of pattern matching with movlp pattern fragment

llvm-svn: 112694

by 112440 are resolved.

llvm-svn: 112692

llvm-svn: 112689

llvm-svn: 112687

This patch was developed on top of original patch by Artur Pietrek.

llvm-svn: 112678

instead of hoisting them, just fold them away.  This occurs in the
testcase for PR8041, for example.

llvm-svn: 112669

and output the dwarf line number tables.  This takes the current loc info after
an instruction is assembled and saves the needed info into an object that has
vector and for each section.  These objects will be used for the final patch to 
build and emit the encoded dwarf line number tables.  Again for now this is only
in the Mach-O streamer but at some point will move to a more generic place.

llvm-svn: 112668

llvm-svn: 112667

llvm-svn: 112666

inner loop doesn't update all the variables in the outer loop.

llvm-svn: 112665

int x(int t) {
  if (t & 256)
    return -26;
  return 0;
}

We generate this:

     tst.w   r0, #256
     mvn     r0, #25
     it      eq
     moveq   r0, #0

while gcc generates this:

     ands    r0, r0, #256
     it      ne
     mvnne   r0, #25
     bx      lr

Scandalous really!

During ISel time, we can look for this particular pattern. One where we have a
"MOVCC" that uses the flag off of a CMPZ that itself is comparing an AND
instruction to 0. Something like this (greatly simplified):

  %r0 = ISD::AND ...
  ARMISD::CMPZ %r0, 0         @ sets [CPSR]
  %r0 = ARMISD::MOVCC 0, -26  @ reads [CPSR]

All we have to do is convert the "ISD::AND" into an "ARM::ANDS" that sets [CPSR]
when it's zero. The zero value will all ready be in the %r0 register and we only
need to change it if the AND wasn't zero. Easy!

llvm-svn: 112664

llvm-svn: 112662

llvm-svn: 112661

llvm-svn: 112659

llvm-svn: 112657

llvm-svn: 112654

No CCR virtual registers should exist, and %EFLAGS is used in ways that can
surprise RegAllocFast.

llvm-svn: 112650

Reserved registers are unpredictable, and are treated as always live by machine
DCE.

Allocatable registers are never reserved, and can be used for virtual registers.

Unreserved, unallocatable registers can not be used for virtual registers, but
otherwise behave like a normal allocatable register. Most targets only have
the flag register in this set.

llvm-svn: 112649

llvm-svn: 112644

llvm-svn: 112643

llvm-svn: 112642

llvm-svn: 112638

More cleanups of my JumpThreading transforms, including extracting some duplicated code into a helper function.

llvm-svn: 112634

llvm-svn: 112632