[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

llvm-svn: 188919

llvm-svn: 188917

llvm-svn: 188916

llvm-svn: 188915

        def imm0_63 : Operand<i32>, ImmLeaf<i32, [{ return Imm >= 0 && Imm < 63;}]>{
As it seems Imm <63 should be Imm <= 63. ImmLeaf is used in pattern match, but there is already a function check the shift amount range, so just remove ImmLeaf. Also add a test to check 63.

llvm-svn: 188911

These tests are failing on Haswell CPUs due to different instruction selection.

llvm-svn: 188908

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

llvm-svn: 188904

Offset in mmap(3) should be aligned to gepagesize(), 64k, or mmap(3) would fail.

TODO: Invetigate places where 4096 would be required as pagesize, or 4096 would satisfy.
llvm-svn: 188903

According to the ARM specification, "mov" is a valid mnemonic for all Thumb2 MOV encodings.
To achieve this, the patch adds one instruction alias with a special range condition to avoid collision with the Thumb1 MOV.

llvm-svn: 188901

llvm-svn: 188899

The initial port used MLG(R) for i64 UMUL_LOHI but left the other three
combinations as not-legal-or-custom.  Although 32x32->{32,32}
multiplications exist, they're not as quick as doing a normal 64-bit
multiplication, so it didn't seem like i32 SMUL_LOHI and UMUL_LOHI
would be useful.  There's also no direct instruction for i64 SMUL_LOHI,
so it needs to be implemented in terms of UMUL_LOHI.

However, not defining these patterns means that we don't convert
division by a constant into multiplication, so this patch fills
in the other cases.  The new i64 SMUL_LOHI sequence is simpler
than the one that we used previously for 64x64->128 multiplication,
so int-mul-08.ll now tests the full sequence.

llvm-svn: 188898

llvm-svn: 188897

I accidentally changed the encoding of the MSA registers to zero instead of 0
to 31. This change restores the encoding the registers had prior to r188893.

This didn't show up in the existing tests because direct-object emission isn't
implemented yet for MSA.

llvm-svn: 188896

llvm-svn: 188895

These are extensions of the existing FI[EDX]BR instructions, but use a spare
bit to suppress inexact conditions.

llvm-svn: 188894

No functional change

llvm-svn: 188893

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

llvm-svn: 188888

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

This is the behavior of sequential disassemblers (llvm-objdump, ...),
when there is no instruction size hint (fixed-length, ...)

While there, also do some minor cleanup.

llvm-svn: 188883

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

llvm-svn: 188878

llvm-svn: 188877

llvm-svn: 188876

Also, drive-by cleaning around createFunction.

llvm-svn: 188875

llvm-svn: 188874

llvm-svn: 188873

llvm-svn: 188872

While there, switch to new-style documentation.

llvm-svn: 188871

Summary:
LLVM would generate DWARF with version 3 in the .debug_pubname and
.debug_pubtypes version fields.  This would lead SGI dwarfdump to fail
parsing the DWARF with (in the instance of .debug_pubnames) would exit
with:
dwarfdump ERROR:  dwarf_get_globals: DW_DLE_PUBNAMES_VERSION_ERROR (123)

This fixes PR16950.

Reviewers: echristo, dblaikie

Reviewed By: echristo

CC: cfe-commits

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

llvm-svn: 188869

Synchronize VEX JIT encoding code with the MCJIT version. Fix a bug in the MCJIT code where CurOp was being incremented even if the operand it was pointing at wasn't used. Maybe only matters if there are any EVEX_K instructions that aren't VEX_4V.

llvm-svn: 188868

In LLVM FMA3 operands are dst, src1, src2, src3, however dst is not encoded as it is always src1. This was causing the encoding of the operands to be off by one.

Patch by Chris Bieneman.

llvm-svn: 188866