llvm-svn: 82038

llvm-svn: 82034

and use MachineModuleInfoMachO instead.

llvm-svn: 82022

llvm-svn: 82020

stuff common across all macho targets.

llvm-svn: 82018

llvm-svn: 82012

llvm-svn: 82011

the global variable list only happen for COFF targets.

llvm-svn: 82010

we have MCInstPrinter.

llvm-svn: 82006

llvm-svn: 81999

trying to create RMW opportunities in the x86 backend.  This can cause a 
cycle to appear in the graph, since the other uses may eventually feed into
the TokenFactor we are sinking the load below.

llvm-svn: 81996

frame, to the Intel instruction tables.

llvm-svn: 81995

the Intel instruction tables.

The patterns will stay blank because ADD reg, reg
is faster, but having the encoding available is
useful for the disassembler.

llvm-svn: 81994

more than one phi, since that leads to higher register pressure on
entry to the phi. This is especially problematic when the phi is in
a loop header, as it increases register pressure throughout the loop.

llvm-svn: 81993

covered by other definitions.

llvm-svn: 81992

Eliminate the PersonalityPrefix/Suffix & NeedsIndirectEncoding
fields from MAI: they aren't part of the asm syntax, they are
related to the structure of the object file.

To replace their functionality, add a new 
TLOF::getSymbolForDwarfGlobalReference method which asks targets
to decide how to reference a global from EH in a pc-relative way.

The default implementation just returns the symbol.  The default
darwin implementation references the symbol through an indirect
$non_lazy_ptr stub.  The bizarro x86-64 darwin specialization
handles the weird "foo@GOTPCREL+4" hack.

DwarfException.cpp now uses this to emit the reference to the
symbol in the right way, and this also eliminates another 
horrible hack from DwarfException.cpp:

-    if (strcmp(MAI->getPersonalitySuffix(), "+4@GOTPCREL"))
-      O << "-" << MAI->getPCSymbol();

llvm-svn: 81991

llvm-svn: 81985

the same time.

llvm-svn: 81984

All of these do not have patterns (they're for the
disassembler).

Many of the floating-point instructions will probably
be rolled into definitions that have patterns, and may
eventually be superseded by mdefs.  So I put them
together and left a comment.

llvm-svn: 81979

llvm-svn: 81970

llvm-svn: 81969

one implementation into its one caller.  This eliminates a totally
awesome and gratuitous hack where we casted a Function* to 
GlobalVariable*.

llvm-svn: 81967

llvm-svn: 81966

and use PersonalityPrefix/Suffix to achieve the same effect (like
the x86 backend).

This changes the code generated for ppc static mode, but guess what,
we were generating this before:

	.byte	0x9B                                        ; Personality (indirect pcrel sdata4)
	.long	___gxx_personality_v0-.                     ; Personality

which is not correct! (it is not an 'indirect' reference).
 

llvm-svn: 81965

it into all of its call sites and simplifying them.

llvm-svn: 81962

llvm-svn: 81961

Radar 7200803.  (This should also fix the
SingleSource/UnitTests/Vector/sumarray-dbl test.)

llvm-svn: 81959

code in other segments) to the Intel instruction
tables.

llvm-svn: 81953

llvm-svn: 81946

llvm-svn: 81942

move MachineFunctionInfo virtual method out of line to give it
a home.

llvm-svn: 81940

SVOffsets.

llvm-svn: 81937

llvm-svn: 81928

llvm-svn: 81923

Intel tables, where the source operand is
specified by the R/M field and the destination
operand by the Reg field.

llvm-svn: 81914

 - As best I can tell, we have eliminated all the code which used to require a
   larger buffer size.

llvm-svn: 81912

llvm-svn: 81909

Better solution for tracking both the original alignment of the access, and the current alignment based
on the source value offset.  This avoids increasing the size of mem nodes. 

llvm-svn: 81897

to the Intel register table.
Added 16- and 64-bit MOVs to and from the segment
registers to the Intel instruction tables.

llvm-svn: 81895

interrupt instruction, which shouldn't arise any other way).  0xcd is
also used by JITMemoryManager to initialize the buffer to garbage,
which means it could appear following a noreturn call even when
that is not a stub, confusing X86CompilationCallback2.  PR 4929.

llvm-svn: 81888