These files are intended to live in the msbuild toolset directory, which
is somewhere like:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\
  v4.0\Platforms\Win32\PlatformToolsets\llvm

More work is needed to install them as part of the NSIS installer.

Patch by Warren Hunt!

llvm-svn: 189411

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

Revert "Fix the build broken by r189315." and "Move everything depending on Object/MachOFormat.h over to Support/MachO.h."

This reverts commits r189319 and r189315. r189315 broke some tests on what I
believe are big-endian platforms.

llvm-svn: 189321

(this triggered Clang's -Wsometimes-uninitialized on the default path
through the switch)

llvm-svn: 189319

llvm-svn: 189315

  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

llvm-svn: 189250

It looked misplaced in the main CMakeLists.txt file.

llvm-svn: 189230

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

lto/CMakeLists.txt: Cut the dep to intrinsics_gen. LTO doesn't depend on it and LTO_static doesn't depend on anything.

llvm-svn: 189086

[CMake] Automatically pick up subdirectories in llvm/tools as 'external projects' if they contain a 'CMakeLists.txt' file.

Allow CMake to pick up external projects in llvm/tools without the need to modify the "llvm/tools/CMakeLists.txt" file.
This makes it easier to work with projects that live in other repositories, without needing to specify each one in "llvm/tools/CMakeLists.txt".

llvm-svn: 188921

Drive-by llvm-objdump cleanup (don't hardcode ToolName).

llvm-svn: 188904

Like yaml ObjectFiles, this will be very useful for testing the MC CFG
implementation (mostly MCObjectDisassembler), by matching the output
with YAML, and for potential users of the MC CFG, by using it as an input.

There isn't much to the actual format, it is just a serialization of the
MCModule class. Of note:
  - Basic block references (pred/succ, ..) are represented by the BB's
    start address.
  - Just as in the MC CFG, instructions are MCInsts with a size.
  - Operands have a prefix representing the type (only register and
    immediate supported here).
  - Instruction opcodes are represented by their names; enum values aren't
    stable, enum names mostly are: usually, a change to a name would need
    lots of changes in the backend anyway.
    Same with registers.

All in all, an example is better than 1000 words, here goes:

A simple binary:

  Disassembly of section __TEXT,__text:
  _main:
  100000f9c:      48 8b 46 08             movq    8(%rsi), %rax
  100000fa0:      0f be 00                movsbl  (%rax), %eax
  100000fa3:      3b 04 25 48 00 00 00    cmpl    72, %eax
  100000faa:      0f 8c 07 00 00 00       jl      7 <.Lend>
  100000fb0:      2b 04 25 48 00 00 00    subl    72, %eax
  .Lend:
  100000fb7:      c3                      ret

And the (pretty verbose) generated YAML:

  ---
  Atoms:
    - StartAddress:    0x0000000100000F9C
      Size:            20
      Type:            Text
      Content:
        - Inst:            MOV64rm
          Size:            4
          Ops:             [ RRAX, RRSI, I1, R, I8, R ]
        - Inst:            MOVSX32rm8
          Size:            3
          Ops:             [ REAX, RRAX, I1, R, I0, R ]
        - Inst:            CMP32rm
          Size:            7
          Ops:             [ REAX, R, I1, R, I72, R ]
        - Inst:            JL_4
          Size:            6
          Ops:             [ I7 ]
    - StartAddress:    0x0000000100000FB0
      Size:            7
      Type:            Text
      Content:
        - Inst:            SUB32rm
          Size:            7
          Ops:             [ REAX, REAX, R, I1, R, I72, R ]
    - StartAddress:    0x0000000100000FB7
      Size:            1
      Type:            Text
      Content:
        - Inst:            RET
          Size:            1
          Ops:             [  ]
  Functions:
    - Name:            __text
      BasicBlocks:
        - Address:         0x0000000100000F9C
          Preds:           [  ]
          Succs:           [ 0x0000000100000FB7, 0x0000000100000FB0 ]
     <snip>
  ...

llvm-svn: 188890

FIXME: Would it be responsible to provide GOT?
llvm-svn: 188855

llvm-svn: 188386

I have moved this logic into clang and opt.

llvm-svn: 188281

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

llvm-svn: 188200

  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

llvm-svn: 188066

Currently, when an invalid attribute is encountered on processing a .s file,
clang will abort due to llvm_unreachable.  Invalid user input should not cause
an abnormal termination of the compiler.  Change the interface to return a
boolean to indicate the failure as a first step towards improving hanlding of
malformed user input to clang.

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

Revert r185882. This is causing problems with the gold linker and might be better handled by the linker.

llvm-svn: 188029

* ELFTypes.h contains template magic for defining types based on endianess, size, and alignment.
* ELFFile.h defines the ELFFile class which provides low level ELF specific access.
* ELFObjectFile.h contains ELFObjectFile which uses ELFFile to implement the ObjectFile interface.

llvm-svn: 188022

As of this revision, all functions of LTOCodeGenerator are consistent in
ret-true-on-succ.

Tested on multiple OSes.

llvm-svn: 187864

llvm-svn: 187819

Patch by: Mei Ye

llvm-svn: 187764

llvm-svn: 187761

llvm-svn: 187739

llvm-svn: 187699

Dyld never outlives MemMgr, just put both on the stack.

llvm-svn: 187697

The ExtractLoops function tries to reduce the failing test case by extracting
one or more loops from the misoptimized piece of the program. In doing this,
ExtractLoops must keep the MiscompiledFunctions vector up-to-date by ensuring
that the pointers refer to functions in the current failing program.
Unfortunately, this is not trivial because:

 - ExtractLoops is iterative, and there are several early exits (and the
   MiscompiledFunctions vector must be consistent with the current program at
every non-fatal exit point).
 - Several of the utility functions used by ExtractLoops (such as
   TestOptimizer, some of which are called through the TestFn callback
parameter, and Linker::LinkModules) delete their inputs upon success.

This change adds several updates of the MiscompiledFunctions vector at
different points. The first is after the initial call to TestMergedProgram
which checks that the loop-extracted program still works. The second is after
the call to TestFn (TestOptimizer, for example). This function will delete its
inputs (which is why the existing ExtractLoops logic cloned the inputs first).

llvm-svn: 187674

Patch by Benjamin Scarlet!

llvm-svn: 187641

Function attributes are the future! So just query whether we want to realign the
stack directly from the function instead of through a random target options
structure.

llvm-svn: 187618

If no other operation is specified, 's' becomes an operation instead of an
modifier. The s operation just creates a symbol table. It is the same as
running ranlib.

We assume the archive was created by a sane ar (like llvm-ar or gnu ar) and
if the symbol table is present, then it is current. We use that to optimize
the most common case: a broken build system that thinks it has to run ranlib.

llvm-svn: 187353

Merge consecutive if-regions if they contain identical statements.
Both transformations reduce number of branches.  The transformation
is guarded by a target-hook, and is currently enabled only for +R600,
but the correctness has been tested on X86 target using a variety of
CPU benchmarks.

Patch by: Mei Ye

llvm-svn: 187278

Approval in here http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064169.html

llvm-svn: 187145

There's no need to specify a flag to omit frame pointer elimination on non-leaf
nodes...(Honestly, I can't parse that option out.) Use the function attribute
stuff instead.

llvm-svn: 187093

The main observation is that we never need both the filesize and the map size.
When mapping a slice of a file, it doesn't make sense to request a null
terminator and that would be the only case where the filesize would be used.

There are other cleanups that should be done in this area:

* A client should not have to pass the size (even an explicit -1) to say if
  it wants a null terminator or not, so we should probably swap the argument
  order.
* The default should be to not require a null terminator. Very few clients
  require this, but many end up asking for it just because it is the default.

llvm-svn: 186984

The gold plugin was passing the desired map size as the file size. This was
working for two reasons:
* Recent version of gold provide the get_view callback, so this code was not
  used.
* In older versions, getOpenFile was called, but the file size is never used
  if we don't require null terminated buffers and map size defaults to the
  file size.

Thanks to Eli Bendersky for noticing this.

I will try to make this api a bit less error prone.

llvm-svn: 186978

llvm-svn: 186935