recovering by adding empty parenthesis. Fixes PR16676!

llvm-svn: 188920

llvm-svn: 188919

llvm-svn: 188918

llvm-svn: 188917

llvm-svn: 188916

llvm-svn: 188915

setter/getter implementations, migrate them to
nonatomic properties.

llvm-svn: 188914

setFeatureEnabled is never called with "32" or "64". The driver never passes it
and mips' getDefaultFeatures sets the Features map directly.

llvm-svn: 188913

llvm-svn: 188912

        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

This is a partial revert of r188817 now that the driver handles -target-feature
in a single place.

llvm-svn: 188910

[CGF] Get rid of passing redundant VTable pointer around in CodeGenFunction::InitializeVTablePointer[s]

llvm-svn: 188909

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

llvm-svn: 188908

llvm-svn: 188907

No functionality change other than changing the order of -target-feature
relative to other -cc1 command line arguments.

llvm-svn: 188906

llvm-svn: 188905

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

Thanks for Craig Topper for noticing it.

llvm-svn: 188902

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

1. We now print the return type of lambdas and return type deduced functions
as "auto". Trailing return types with decltype print the underlying type.
2. Use the lambda or block scope for the PredefinedExpr type instead of the
parent function. This fixes PR16946, a strange mismatch between type of the
expression and the actual result.
3. Verify the type in CodeGen.
4. The type for blocks is still wrong. They are numbered and the name is not
known until CodeGen.

llvm-svn: 188900

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

llvm-svn: 188892

Before:
  if (!aaaaaaaaaa(  // break
          aaaaa)) {
  }

After:
  if (!aaaaaaaaaa(  // break
           aaaaa)) {
  }

Also cleaned up formatting using clang-format.

llvm-svn: 188891

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