This should fix the MSVC build.

llvm-svn: 191357

This reverts r191030

llvm-svn: 191075

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

llvm-svn: 191030

This avoids warnings when included in a application that
uses -Wstrict-prototypes.

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

llvm-svn: 191029

----
  Add new API lto_codegen_compile_parallel().

  This API is proposed by Nick Kledzik. The semantic is:

  --------------------------------------------------------------------------
   Generate code for merged module into an array of native object files. On 
   success returns a pointer to an array of NativeObjectFile.  The count 
   parameter returns the number of elements in the array.  Each element is 
   a pointer/length for a generated mach-o/ELF buffer.  The buffer is owned
   by the lto_code_gen_t and will be freed when lto_codegen_dispose() is called, 
   or lto_codegen_compile() is called again. On failure, returns NULL 
   (check lto_get_error_message() for details).

   extern const struct  NativeObjectFile*
   lto_codegen_compile_parallel(lto_code_gen_t cg, size_t *count);
  ---------------------------------------------------------------------------

  This API is currently only called on OSX platform. Linux or other Unixes
using GNU gold are not supposed to call this function, because on these systems, 
object files are fed back to linker via disk file instead of memory buffer.

  In this commit, lto_codegen_compile_parallel() simply calls
lto_codegen_compile() to return a single object file. In the near future,
this function is the entry point for compilation with partition. Linker can
blindly call this function even if partition is turned off; in this case,
compiler will return only one object file.

llvm-svn: 189386

  This API is proposed by Nick Kledzik. The semantic is:

  --------------------------------------------------------------------------
   Generate code for merged module into an array of native object files. On 
   success returns a pointer to an array of NativeObjectFile.  The count 
   parameter returns the number of elements in the array.  Each element is 
   a pointer/length for a generated mach-o/ELF buffer.  The buffer is owned
   by the lto_code_gen_t and will be freed when lto_codegen_dispose() is called, 
   or lto_codegen_compile() is called again. On failure, returns NULL 
   (check lto_get_error_message() for details).

   extern const struct  NativeObjectFile*
   lto_codegen_compile_parallel(lto_code_gen_t cg, size_t *count);
  ---------------------------------------------------------------------------

  This API is currently only called on OSX platform. Linux or other Unixes
using GNU gold are not supposed to call this function, because on these systems, 
object files are fed back to linker via disk file instead of memory buffer.

  In this commit, lto_codegen_compile_parallel() simply calls
lto_codegen_compile() to return a single object file. In the near future,
this function is the entry point for compilation with partition. Linker can
blindly call this function even if partition is turned off; in this case,
compiler will return only one object file.

llvm-svn: 189297

This function attribute indicates that the function is not optimized
by any optimization or code generator passes with the 
exception of interprocedural optimization passes.

llvm-svn: 189101

...so that it can be used for z too.  Most of the code is the same.
The only real change is to use TargetTransformInfo to test when a sqrt
instruction is available.

The pass is opt-in because at the moment it only handles sqrt.

llvm-svn: 189097

llvm-svn: 188589

In order to appease people (in Apple) who accuse me for committing "huge change" (?) without proper review. 

Thank Eric for fixing a compile-warning. 

llvm-svn: 188204

  1. Add some helper classes for partitions. They are designed in a
     way such that the top-level LTO driver will not see much difference 
     with or without partitioning.

  2. Introduce work-dir. Now all intermediate files generated during 
     LTO phases will be saved under work-dir. User can specify the workdir
     via -lto-workdir=/path/to/dir. By default the work-dir will be 
     erased before linker exit. To keep the workdir, do -lto-keep, or -lto-keep=1.

    TODO: Erase the workdir, if the linker exit prematurely.  
      We are currently not able to remove directory on signal. The support 
      routines simply ignore directory.

  3. Add one new API lto_codegen_get_files_need_remove().
     Linker and LTO plugin will communicate via this API about which files
    (including directories) need to removed before linker exit.

llvm-svn: 188188

Other than recognizing the attribute, the patch does little else.
It changes the branch probability analyzer so that edges into
blocks postdominated by a cold function are given low weight.

Added analysis and code generation tests.  Added documentation for the
new attribute.

llvm-svn: 182638

the C API to provide their own way of allocating JIT memory (both code 
and data) and finalizing memory permissions (page protections, cache 
flush).

llvm-svn: 182448

llvm-svn: 182409

the C API to provide their own way of allocating JIT memory (both code 
and data) and finalizing memory permissions (page protections, cache 
flush).

llvm-svn: 182408

llvm-svn: 181189

CodeModel: It's now possible to create an MCJIT instance with any CodeModel you like.  Previously it was only possible to 
create an MCJIT that used CodeModel::JITDefault.

EnableFastISel: It's now possible to turn on the fast instruction selector.

The CodeModel option required some trickery.  The problem is that previously, we were ensuring future binary compatibility in 
the MCJITCompilerOptions by mandating that the user bzero's the options struct and passes the sizeof() that he saw; the 
bindings then bzero the remaining bits.  This works great but assumes that the bitwise zero equivalent of any field is a 
sensible default value.

But this is not the case for LLVMCodeModel, or its internal equivalent, llvm::CodeModel::Model.  In both of those, the default 
for a JIT is CodeModel::JITDefault (or LLVMCodeModelJITDefault), which is not bitwise zero.

Hence this change introduces LLVMInitializeMCJITCompilerOptions(), which will initialize the user's options struct with
defaults. The user will use this in the same way that they would have previously used memset() or bzero(). MCJITCAPITest.cpp
illustrates the change, as does the comment in ExecutionEngine.h.

llvm-svn: 180893

This avoids namespace collisions with llvm::LLVMTargetMachine.

llvm-svn: 180891

Re-submitting with fix for OCaml dependency problems (removing dependency on SectionMemoryManager when it isn't used).

Patch by Fili Pizlo

llvm-svn: 180720

This reverts commit 8c31b298149ca3c3f2bbd9e8aa9a01c4d91f3d74.

It looks like this commit broke some bots:

http://lab.llvm.org:8011/builders/llvm-ppc64-linux2/builds/5209

llvm-svn: 180248

Patch by Filip Pizlo

llvm-svn: 180229

llvm-svn: 180104

llvm-svn: 180100

or the C++ files themselves. This enables people to use
just a C compiler to interoperate with LLVM.

llvm-svn: 180063

llvm-svn: 179785

llvm-svn: 179648

llvm-svn: 179647

llvm-svn: 179646

llvm-svn: 179645

LLVMGetThreadLocalMode - exposes GlobalVariable::getThreadLocalMode
LLVMSetThreadLocalMode - exposes GlobalVariable::setThreadLocalMode
LLVMIsExternallyInitialized - exposes GlobalVariable::isExternallyInitialized
LLVMSetExternallyInitialized - exposes GlobalVariable::setExternallyInitialized
LLVMThreadLocalMode - maps to GlobalVariable::ThreadLocalMode

Patch by Moritz Maxeiner!

llvm-svn: 179588

Rename the C function to create a SLPVectorizerPass to something sane and expose it in the header file.

llvm-svn: 179272

llvm-svn: 178769

llvm-svn: 178713

llvm-svn: 176793

Maxeiner.

llvm-svn: 175398

llvm-svn: 175203

 
 LLVMCreateMemoryBufferWithMemoryRange - exposes MemoryBuffer::getMemBuffer
 LLVMCreateMemoryBufferWithMemoryRangeCopy - exposes MemoryBuffer::getMemBufferCopy

Patch by Moritz Maxeiner!

llvm-svn: 175199

Extracted ObjCARC.cpp into its own library libLLVMObjCARCOpts in preparation for refactoring the ARC Optimizer.

llvm-svn: 173647

SSPStrong applies a heuristic to insert stack protectors in these situations:

* A Protector is required for functions which contain an array, regardless of
  type or length.

* A Protector is required for functions which contain a structure/union which
  contains an array, regardless of type or length.  Note, there is no limit to
  the depth of nesting.

* A protector is required when the address of a local variable (i.e., stack
  based variable) is exposed. (E.g., such as through a local whose address is
  taken as part of the RHS of an assignment or a local whose address is taken as
  part of a function argument.)

This patch implements the SSPString attribute to be equivalent to
SSPRequired. This will change in a subsequent patch.

llvm-svn: 173230

llvm-svn: 172025