an allocation that is greater than what we will actually allocate.

Patch by Artyom Skrobov!

llvm-svn: 189340

Summary:
1) Make llvm-symbolizer properly symbolize
files with split debug info (by using stanalone .dwo files).
2) Make DWARFCompileUnit parse and store corresponding .dwo file,
if necessary.
3) Make bits of DWARF parsing more CompileUnit-oriented.

Reviewers: echristo

Reviewed By: echristo

CC: bkramer, llvm-commits

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

llvm-svn: 189329

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

llvm-svn: 189315

Right now we have two headers for the Mach-O format. I'd like to get rid
of one. Since the other object formats are all in Support, I chose to
keep the Mach-O header in Support, and discard the other one.

llvm-svn: 189314

  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

DICompositeType will have an identifier field at position 14. For now, the
field is set to null in DIBuilder.
For DICompositeTypes where the template argument field (the 13th field)
was optional, modify DIBuilder to make sure the template argument field is set.
Now DICompositeType has 15 fields.

Update DIBuilder to use NULL instead of "i32 0" for null value of a MDNode.
Update verifier to check that DICompositeType has 15 fields and the last
field is null or a MDString.

Update testing cases to include an extra field for DICompositeType.
The identifier field will be used by type uniquing so a front end can
genearte a DICompositeType with a unique identifer.

llvm-svn: 189282

llvm-svn: 189249

This adds minimal support to the SelectionDAG for handling address spaces
with different pointer sizes.  The SelectionDAG should now correctly
lower pointer function arguments to the correct size as well as generate
the correct code when lowering getelementptr.

This patch also updates the R600 DataLayout to use 32-bit pointers for
the local address space.

v2:
  - Add more helper functions to TargetLoweringBase
  - Use CHECK-LABEL for tests

llvm-svn: 189221

llvm-svn: 189199

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

llvm-svn: 189183

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

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

Replace instances of this scattered around the code base.

llvm-svn: 189169

Patch by Ismail Pazarbasi.

llvm-svn: 189162

llvm-svn: 189124

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

llvm-svn: 189117

This fixes a pathological compile time problem with very large blocks
and lots of scheduling boundaries.

llvm-svn: 189116

llvm-svn: 189106

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

This field specifies registers that are preserved across function calls,
but that should not be included in the generates SaveList array.

This can be used ot generate regmasks for architectures that save
registers through other means, like SPARC's register windows.

llvm-svn: 189084

pointers, but accumulate the offset into an APInt in the process of
stripping it.

This is a pretty handy thing to have, such as when trying to determine
if two pointers are at some constant relative offset. I'll be committing
a patch shortly to use it for exactly that purpose.

llvm-svn: 189000

Value. These methods probably don't belong here, and I'm discussing
moving the lot of them to a better home, but for now I'm about to extend
their functionality and wanted to tidy them up first.

llvm-svn: 188997

Back in the mists of time (2008), it seems TableGen couldn't handle the
patterns necessary to match ARM's CMOV node that we convert select operations
to, so we wrote a lot of fairly hairy C++ to do it for us.

TableGen can deal with it now: there were a few minor differences to CodeGen
(see tests), but nothing obviously worse that I could see, so we should
probably address anything that *does* come up in a localised manner.

llvm-svn: 188995

Summary:
This support will be utilized in things like clang to help check printf
format specifiers that are only valid when using the VSCRT.

Reviewers: rnk, asl, chandlerc

Reviewed By: chandlerc

CC: llvm-commits

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

llvm-svn: 188935

llvm-svn: 188933

llvm-svn: 188897

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

llvm-svn: 188889

Used to detect calls to function symbol stubs (future commit).

llvm-svn: 188887

Supports:
- entrypoint, using LC_MAIN.
- static ctors/dtors, using __mod_{init,exit}_func
- translation between effective and object load address, using
  dyld's VM address slide.

llvm-svn: 188886

llvm-svn: 188885

It can now disassemble code in situations where the effective load
address is different than the load address declared in the object file.
This happens for PIC, hence "dynamic".

llvm-svn: 188884

For now, this isn't implemented for any format.

llvm-svn: 188882

When an MCTextAtom is split, all MCBasicBlocks backed by it are
automatically split, with a fallthrough between both blocks, and
the successors moved to the second block.

llvm-svn: 188881

While there, do some minor cleanup.

llvm-svn: 188880

Only implemented in the Mach-O ObjectSymbolizer.
The testcase sadly introduces a new binary.

llvm-svn: 188879