llvm-svn: 75229

llvm-svn: 75228

template.  Also convert it to take a MachineOperand instead of a GV*

llvm-svn: 75227

is modified. Otherwise, the unwinder will get confused. The old code (before I
started my hacking) did this. It dropped on the floor, because I wasn't aware of
this requirement.

On the plus side, if we use "alloca" in a function, we create frame pointers
even with -fomit-frame-pointer is enabled!

This is a Good Thing(tm)!!!

llvm-svn: 75183

gcc.apple/asm-block-13.c
gcc.apple/asm-block-57.c

llvm-svn: 75169

llvm-svn: 75153

llvm-svn: 75142

llvm-svn: 75118

isel.

llvm-svn: 75117

registers based on dynamic conditions. For example, X86 EBP/RBP, when used as
frame register has to be spilled in the first fixed object. It should inform
PEI this so it doesn't get allocated another stack object. Also, it should not
be spilled as other callee-saved registers but rather its spilling and restoring
are being handled by emitPrologue and emitEpilogue. Avoid spilling it twice.

llvm-svn: 75116

llvm-svn: 75113

llvm-svn: 75112

llvm-svn: 75110

mode, instead of having asmprinter just "know" to print them.

llvm-svn: 75109

llvm-svn: 75108

llvm-svn: 75107

is incapable of lowering direct references to globals like this, zap the code.

llvm-svn: 75106

llvm-svn: 75105

asmprinter do it.

llvm-svn: 75104

llvm-svn: 75102

in pic or dynamic-no-pic mode. Also, x86-64 never used picstylegot.

llvm-svn: 75101

Simplify it away, someone should evaluate this.

llvm-svn: 75100

Simplify code based on this.

llvm-svn: 75099

llvm-svn: 75096

llvm-svn: 75095

make sure we're set to static codegen.  Simplify the decision
tree of target->picstyle/picmode settings.

llvm-svn: 75094

with DLLImport symbols even when in -static mode.

llvm-svn: 75093

code which conflated RIPRel PIC with x86-64.  Fix these to just check for X86-64
directly.

llvm-svn: 75092

llvm-svn: 75091

x86-64: GOT-style PIC is never used on x86-64.

llvm-svn: 75090

llvm-svn: 75089

llvm-svn: 75088

llvm-svn: 75086

llvm-svn: 75083

llvm-svn: 75082

llvm-svn: 75080

llvm-svn: 75079

* remove some old code that was needed when we'd put ESP in the scale instead of 
  the base of some instructions.
* Fix a bug with the P modifier in inline asm that caused us to drop it.

llvm-svn: 75077

* remove some dead code: darwin doesn't support dllimport linkage.

llvm-svn: 75066

DWARF requires frame moves be specified at specific times. If you have a
prologue like this:

__Z3fooi:
Leh_func_begin1:
LBB1_0: ## entry
       pushl   %ebp
Llabel1:
       movl    %esp, %ebp
Llabel2:
       pushl   %esi
Llabel3:
       subl    $20, %esp
       call    "L1$pb"
"L1$pb":
       popl    %esi

The "pushl %ebp" needs a table entry specifying the offset. The "movl %esp,
%ebp" makes %ebp the new stack frame register, so that needs to be specified in
DWARF. And "pushl %esi" saves the callee-saved %esi register, which also needs
to be specified in DWARF.

Before, all of this logic was in one method. This didn't work too well, because
as you can see there are multiple FDE line entries that need to be created.

This fix creates the "MachineMove" objects directly when they're needed; instead
of waiting until the end, and losing information.

There is some ugliness where we generate code like this:


LBB22_0:	## entry
	pushl	%ebp
Llabel280:
	movl	%esp, %ebp
Llabel281:
Llabel284:
	pushl	%ebp  <----------
	pushl	%ebx
	pushl	%edi
	pushl	%esi
Llabel282:
	subl	$328, %esp

Notice the extra "pushl %ebp". If we generate a "machine move" instruction in
the FDE for that pushl, the linker may get very confused about what value %ebp
should have when exitting the function. I.e., it'll give it the value %esp
instead of the %ebp value from the first "pushl". Not to mention that, in this
case, %ebp isn't modified in the function (that's a separate bug). I put a small
hack in to get it to work. It might be the only solution, but should be
revisited once the above case is fixed.

llvm-svn: 75047