disassembled output alongside the instructions.
E.g., on a vector shuffle operation with a memory operand, disassembled
outputs are:
* Without the option:
    vpshufd $-0x79, (%rsp), %xmm0
    
* With the option:
    vpshufd $-0x79, (%rsp), %xmm0   ## Latency: 5

The printed latency is extracted from the schedule model available in the
disassembler context. Thus, this option has no effect if there is not a
scheduling model for the target.
This boils down to one may need to specify the CPU string, so that this
option could have an effect.

Note: Latency < 2 are not printed.

This part of <rdar://problem/14687488>.

llvm-svn: 191859

This threads SectionName through the allocateCodeSection/allocateDataSection APIs, both in C++ and C land.  
It's useful for the memory managers that are allocating a section to know what the name of the section is.  
At a minimum, this is useful for low-level debugging - it's customary for JITs to be able to tell you what 
memory they allocated, and as part of any such dump, they should be able to tell you some meta-data about 
what each allocation is for.  This allows clients that supply their own memory managers to do this.  
Additionally, we also envision the SectionName being useful for passing meta-data from within LLVM to an LLVM 
client.

This changes both the C and C++ APIs, and all of the clients of those APIs within LLVM.  I'm assuming that 
it's safe to change the C++ API because that API is allowed to change.  I'm assuming that it's safe to change 
the C API because we haven't shipped the API in a release yet (LLVM 3.3 doesn't include the MCJIT memory 
management C API).

llvm-svn: 191804

comments issued with verbose assembly.
E.g., on a vector shuffle operation, disassembled output are:
* Without the option:
vpshufd $-0x79, (%rsp), %xmm0

* With the option:
vpshufd $-0x79, (%rsp), %xmm0   ## xmm0 = mem[3,1,0,2]

This part of <rdar://problem/14687488>.

llvm-svn: 191799

This makes it consistent with other function pointers used in llvm-c

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

llvm-svn: 191693

llvm-svn: 191359

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