llvm-svn: 198536

llvm-svn: 198533

Mark the 64-bit x86 push/pop instructions as In64BitMode. Mark the corresponding 32-bit versions with the same encodings Not64BitMode. Remove hack from tablegen disassembler table emitter. Fix bad test.

llvm-svn: 198530

llvm-svn: 198437

llvm-svn: 198313

Remove need for MODIFIER_OPCODE in the disassembler tables. AddRegFrms are really more like OrRegFrm so we don't need a difference since we can just mask bits.

llvm-svn: 198278

llvm-svn: 198269

llvm-svn: 198268

Revert r198238 and add FP disassembler tests. It didn't work and I didn't realized we had no FP disassembler test cases.

llvm-svn: 198265

Checking the trailing letter of the mnemonic is insufficient.  Be more thorough
in the scanning of the instruction to ensure that we correctly work with the
predicated mnemonics.

llvm-svn: 198235

In order to provide compatibility with the GNU assembler, provide aliases for
pre-UAL mnemonics for floating point operations.

llvm-svn: 198172

Avoid double diagnostics for invalid expressions for count.  Improve caret
location for negative count.

llvm-svn: 198099

The GNU assembler supports .rep as an alias for .rept.  This simply creates the
alias for it and introduces a test for both .rept and .rep.

llvm-svn: 198097

of architecture naming.

llvm-svn: 198043

The .even directive aligns content to an evan-numbered address.  This is an ARM
specific directive applicable to any section.

llvm-svn: 198031

llvm-svn: 198013

llvm-svn: 198010

llvm-svn: 198009

llvm-svn: 197984

The bkpt mnemonic has an implicit immediate constant of 0 unless otherwise
specified.  Add an instruction alias for the unvalued breakpoint mnemonic to
treat it as a 0.  This improves compatibility with GNU AS.

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

llvm-svn: 197828

llvm-svn: 197815

The .pool directive is an alias for the .ltorg directive used to create a
literal pool.  Simply treat .pool as if .ltorg was passed.

llvm-svn: 197787

this commit as the only one on the Blamelist so I quickly reverted this.
However it was actually Nick's change who has since fixed that issue.

Original commit message:

Changed the X86 assembler for intel syntax to work with directional labels.

The X86 assembler as a separate code to parser the intel assembly syntax
in X86AsmParser::ParseIntelOperand().  This did not parse directional labels.
And if something like 1f was used as a branch target it would get an
"Unexpected token" error.

The fix starts in X86AsmParser::ParseIntelExpression() in the case for
AsmToken::Integer, it needs to grab the IntVal from the current token
then look for a 'b' or 'f' following an Integer.  Then it basically needs to
do what is done in AsmParser::parsePrimaryExpr() for directional
labels.  It saves the MCExpr it creates in the IntelExprStateMachine
in the Sym field.

When it returns to X86AsmParser::ParseIntelOperand() it looks
for a non-zero Sym field in the IntelExprStateMachine and if
set it creates a memory operand not an immediate operand
it would normally do for the Integer.

rdar://14961158

llvm-svn: 197744

directional labels.  Because it doesn't work for windows :)

llvm-svn: 197731

The X86 assembler has a separate code to parser the intel assembly syntax
in X86AsmParser::ParseIntelOperand().  This did not parse directional labels.
And if something like 1f was used as a branch target it would get an
"Unexpected token" error.

The fix starts in X86AsmParser::ParseIntelExpression() in the case for
AsmToken::Integer, it needs to grab the IntVal from the current token
then look for a 'b' or 'f' following the Integer.  Then it basically needs to
do what is done in AsmParser::parsePrimaryExpr() for directional
labels.  It saves the MCExpr it creates in the IntelExprStateMachine
in the Sym field.

When it returns to X86AsmParser::ParseIntelOperand() it looks
for a non-zero Sym field in the IntelExprStateMachine and if
set it creates a memory operand not an immediate operand
it would normally do for the Integer.

rdar://14961158

llvm-svn: 197728

This directive will write out the assembler-maintained constant
pool for the current section. These constant pools are created to
support the ldr-pseudo instruction (e.g. ldr r0, =val).

The directive can be used by the programmer to place the constant
pool in a location that can be reached by a pc-relative offset in
the ldr instruction.

llvm-svn: 197711

The ldr-pseudo opcode is a convenience for loading 32-bit constants.
It is converted into a pc-relative load from a constant pool. For
example,

  ldr r0, =0x10001
  ldr r1, =bar

will generate this output in the final assembly

  ldr r0, .Ltmp0
  ldr r1, .Ltmp1
  ...
  .Ltmp0: .long 0x10001
  .Ltmp1: .long bar

Sketch of the LDR pseudo implementation:
  Keep a map from Section => ConstantPool

  When parsing ldr r0, =val
    parse val as an MCExpr
    get ConstantPool for current Section
    Label = CreateTempSymbol()
    remember val in ConstantPool at next free slot
    add operand to ldr that is MCSymbolRef of Label

  On finishParse() callback
    Write out all non-empty constant pools
    for each Entry in ConstantPool
      Emit Entry.Label
      Emit Entry.Value

Possible improvements to be added in a later patch:
  1. Does not convert load of small constants to mov
     (e.g. ldr r0, =0x1 => mov r0, 0x1)
  2. Does reuse constant pool entries for same constant

The implementation was tested for ARM, Thumb1, and Thumb2 targets on
linux and darwin.

llvm-svn: 197708

llvm-svn: 197696

The tests for the disassembler were adapted from the encoder tests, and for the
most part, the output from the disassembler matches that encoder-test inputs.
There are some places where more-informative mnemonics could be produced
(notably for the branch instructions), and those cases are noted in the tests
with FIXMEs.

Future work includes:

 - Generating more-informative mnemonics when possible (this may also be done
   in the printer).

 - Remove the dependence on positional "numbered" operand-to-variable mapping
   (for both encoding and decoding).

 - Internally using 64-bit instruction variants in 64-bit mode (if this turns
   out to matter).

llvm-svn: 197693

llvm-svn: 197692

llvm-svn: 197685

This adds support for the .inst directive.  This is an ARM specific directive to
indicate an instruction encoded as a constant expression.  The major difference
between .word, .short, or .byte and .inst is that the latter will be
disassembled as an instruction since it does not get flagged as data.

llvm-svn: 197657

1. The arch directive now appears before the cpu directive
2. Long run lines were split across multiple lines
    
No functional changes.

llvm-svn: 197588

   
No functional changes.

llvm-svn: 197559

The .end directive indicates the end of the file.  No further instructions are
processed after a .end directive is encountered.

One potential (glaringly obvious) optimisation that could be pursued here is to
extend MCAsmParser with a DiscardRemainder method to avoid processing lexemes to
the end of the file.  It was unclear at this point if that would be worth
adding, and could easily be added in a follow on change.

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

Without this, assembling clang's disassembly would produce an object
file with the IMAGE_SCN_CNT_INITIALIZED_DATA section characteristic
rather than the uninitialized one.  link.exe would warn when merging
comdats with different flags.

llvm-svn: 197529

The branch offset for a R_MIPS_PC16 relocation is indeed a 16-bit signed
immediate.

llvm-svn: 197506

were falling into the cases for 24-bit branch kinds which are not 24-bit
branches.  The routine is to return false for fixups are expected to always
be resolvable at assembly time. Which these three fixups are as they have
limited displacement and are for local references within a function.

rdar://15586725

llvm-svn: 197282

llvm-svn: 197255