to the Intel instruction tables.

llvm-svn: 82081

llvm-svn: 82080

llvm-svn: 82077

constants out of loops. These aren't covered by the regular LICM
pass, because in LLVM IR constants don't require separate
instructions. They're not always covered by the MachineLICM pass
either, because it doesn't know how to unfold folded constant-pool
loads. This is somewhat experimental at this point, and off by
default.

llvm-svn: 82076

llvm-svn: 82075

llvm-svn: 82074

llvm-svn: 82064

llvm-svn: 82063

This interface will be used to attach metadata with an instruction.

llvm-svn: 82060

llvm-svn: 82054

phis, similar to the FoldPHIArgGEPIntoPHI change.

Also, delete some comments that don't reflect the code.

llvm-svn: 82053

failures.

llvm-svn: 82040

(See http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090907/086737.html and
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090907/086746.html)

llvm-svn: 82039

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