First chunk of actual fast-isel selection code.  This handles direct
and indirect branches, as well as feeding compares for direct
branches.  PPCFastISel::PPCEmitIntExt() is just roughed in and will be
expanded in a future patch.  This also corrects a problem with
selection for constant pool entries in JIT mode or with small code
model.

llvm-svn: 189202

First round of fixes for the x86 fixes for the x86 move accumulator from/to memory offset instructions.

-Assembly parser now properly check the size of the memory operation specified in intel syntax. So 'mov word ptr [5], al' is no longer accepted.
-x86-32 disassembly of these instructions no longer sign extends the 32-bit address immediate based on size.
-Intel syntax printing prints the ptr size and places brackets around the address immediate.

Known remaining issues with these instructions:
-Segment override prefix is not supported. PR16962 and PR16961.
-Immediate size should be changed by address size prefix.

llvm-svn: 189201

llvm-svn: 189199

llvm-svn: 189198

llvm-svn: 189195

llvm-svn: 189189

a non-constant GEP.

I don't have any test case that demonstrates this, Nadav (indirectly)
pointed this out in code review. I'm not sure how possible it is to
contrive a test case for the current users of this code that triggers
the bad issue sadly.

llvm-svn: 189188

We currently emit labels with the prefix Lllvm$workaround$fake$stub$ if
the target's MCAsmInfo has getLinkOnceDirective() mapped to something
interesting.  This was apparently a work around introduced in r31033 for
binutils that we don't need anymore.

llvm-svn: 189187

I need to add the rest of these to the list or else to delay putting
out the actual stub until later in code generation when I know if
the external function ever got emitted

Resubmit this patch. The target triple needs to be added to the test so that 
clang does not tell the backend the wrong target when the host is BSD. There
is a clang bug in here somewhere that I need to track down. At Mips this
has been filed internally as a bug.

llvm-svn: 189186

error: commas at the end of enumerator lists are a C++11 extension
[-Werror,-Wc++11-extensions]

llvm-svn: 189183

Add hasSideEffects/mayLoad/mayStore flags to the X86 moffs8/moffs16/moffs32/moffs64 versions of move.

llvm-svn: 189182

This adds additional missing Windows subsystem identifiers to the
IMAGE_SUBSYSTEM enumeration.

Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
llvm-svn: 189180

llvm-svn: 189179

llvm-svn: 189178

llvm-svn: 189176

llvm-svn: 189173

Replace instances of this scattered around the code base.

llvm-svn: 189169

llvm-svn: 189168

Leak found by valgrind.

llvm-svn: 189167

I am going to add in a subsequent patch support for generating the llvm
manpage.

llvm-svn: 189164

Patch by Ismail Pazarbasi.

llvm-svn: 189162

I need to add the rest of these to the list or else to delay putting
out the actual stub until later in code generation when I know if
the external function ever got emitted.

llvm-svn: 189161

This support was removed by accident during the MC conversion

llvm-svn: 189160

llvm-svn: 189158

Differential Revision: http://llvm-reviews.chandlerc.com/D1428

llvm-svn: 189155

llvm-svn: 189146

llvm-svn: 189145

llc using the host cpu features and *waning* on unknown features is probably
not a good thing :-(

llvm-svn: 189144

llvm-svn: 189143

There is no advantage in being different and using the same names simplifies
clang a bit.

llvm-svn: 189141

llvm-svn: 189133

llvm-svn: 189131

Since it's an llvm-internal tool, we shouldn't install it.

(This depends on Clang r189127 and lld r189128.)

llvm-svn: 189130

It was previously not being built on Windows because the cmake file relied
on a sed script to generate a .in file that llvm-config needs.

By using cmake's configure_file function, we can get rid off the sed hack,
and also have this work on Windows.

Differential Revision: http://llvm-reviews.chandlerc.com/D1481

llvm-svn: 189125

llvm-svn: 189124

llvm-svn: 189123

llvm-svn: 189122

llvm-svn: 189121

Estimate the cyclic critical path within a single block loop. If the
acyclic critical path is longer, then the loop will exhaust OOO
resources after some number of iterations. If lag between the acyclic
critical path and cyclic critical path is longer the the time it takes
to issue those loop iterations, then aggressively schedule for
latency.

llvm-svn: 189120

This will be used to compute the cyclic critical path and to
update precomputed per-node pressure differences.
In the longer term, it could also be used to speed up LiveInterval
update by avoiding visiting all global vreg users.

llvm-svn: 189118