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

llvm-svn: 75086

llvm-svn: 75085

llvm-svn: 75084

llvm-svn: 75083

llvm-svn: 75082

nodes with operand types that differ from the result type. (This
doesn't normally happen right now, because
SelectionDAGLowering::visitShuffleVector normalizes vector shuffles.)

llvm-svn: 75081

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

llvm-svn: 75076

llvm-svn: 75074

llvm-svn: 75073

llvm-svn: 75072

llvm-svn: 75071

llvm-svn: 75070

llvm-svn: 75067

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

llvm-svn: 75066

- Make bits 25-27 for ldrh, etc. explicitly zero. Previously only the JIT uses the encoding information and it's assuming anything not specified to be zero. Making them explicit so the disassembler is happy.
Patch by Sean Callanan.

llvm-svn: 75065

llvm-svn: 75061

llvm-svn: 75060

default, this option is not enabled to support clients who rely on
this behavior.

Fixes http://llvm.org/PR4483

A patch to allocate additional memory for globals after we run out is
forthcoming.

Patch by Reid Kleckner!

llvm-svn: 75059

Reformat.

llvm-svn: 75058

  !0 = constant metadata !{...}

llvm-svn: 75057

Allow users of GraphWriter to display graphs asynchronously.  This
provides a way to quickly dump a bunch of graph information to dot files
and display them.  It's a timesaver when working on large systems.

llvm-svn: 75056

Add an ExecuteNoWait interface to support asynchronous process spawning.

llvm-svn: 75055

Simplify MDNode printing.

llvm-svn: 75053

number of elements.  Make some simplifications based
on this (in particular SplitVecRes_SETCC).  Tighten
up some checking while there.

llvm-svn: 75050

Change how so_imm and t2_so_imm are handled. At instruction selection time, the immediates are no longer encoded in the imm8 + rot format, that are left as it is. The encoding is now done in ams printing and code emission time instead.

llvm-svn: 75048

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

llvm-svn: 75046