[PowerPC] Add some FIXMEs

A bunch of extendend mnemomics ought to support '.' forms.
Add FIXMEs to the test case for those.

llvm-svn: 184757

[PowerPC] Add predicted forms of branches

This adds support for the predicted forms of branches (+/-).
There are three cases to consider:
- Branches using a PPC::Predicate code
  For these, I've added new PPC::Predicate codes corresponding
  to the BO values for predicted branch forms, and updated insn
  printing to print them correctly.  I've also added new aliases
  for the asm parser matching the new forms.
- bt/bf
  I've added new aliases matching to gBC etc.
- bd(n)z variants
  I've added new instruction patterns for the predicted forms.

In all cases, the new patterns are used for the asm parser only.
(The new infrastructure ought to be sufficient to allow use by
the compiler too at some point.)

llvm-svn: 184754

[PowerPC] Add t/f branch mnemonics to asm parser

This adds the bt/bf/bd(n)zt/bd(n)zf mnemonics as aliases for the
asm parser, resolving to the generic conditional patterns.

llvm-svn: 184725

[PowerPC] Support generic conditional branches in asm parser

This adds instruction patterns to cover the generic forms of
the conditional branch instructions.  This allows the assembler
to support the generic mnemonics.

The compiler will still generate the various specific forms
of the instruction that were already supported.

llvm-svn: 184722

[PowerPC] Support absolute branches

There is currently only limited support for the "absolute" variants
of branch instructions.  This patch adds support for the absolute
variants of all branches that are currently otherwise supported.

This requires adding new fixup types so that the correct variant
of relocation type can be selected by the object writer.

While the compiler will continue to usually choose the relative
branch variants, this will allow the asm parser to fully support
the absolute branches, with either immediate (numerical) or
symbolic target addresses.

No change in code generation intended.

llvm-svn: 184721

[PowerPC] Support bd(n)zl and bd(n)zlrl

This adds support for the bd(n)zl and bd(n)zlrl instructions.
The patterns are currently used for the asm parser only.

llvm-svn: 184720

[PowerPC] Support b(cond)l in the asm parser

This patch adds support for the conditional variants of bl.
The pattern is currently used by the asm parser only.

llvm-svn: 184719

[PowerPC] Support blrl and variants in the asm parser

This patch adds support for blrl and its conditional variants.
The patterns are (currently) used for the asm parser only.

llvm-svn: 184718

When encoded to thumb, VFP instruction and VMOV/VDUP between scalar and
core registers, must have their predicate bit to 0b1110.

llvm-svn: 184707

llvm-svn: 184706

In thumb1, NOP is a pseudo-instruction equivalent to mov r8, r8.
However the disassembler should not use this alias.

llvm-svn: 184703

mask == 0 -> UNPRED

llvm-svn: 184702

llvm-svn: 184701

llvm-svn: 184667

[PowerPC] Support R_PPC_REL16 family of relocations

The GNU assembler supports (as extension to the ABI) use of PC-relative
relocations in half16 fields, which allows writing code like:

  li 1, base-.

This patch adds support for those relocation types in the assembler.

llvm-svn: 184552

[PowerPC] Support various tls-related modifiers

The current code base only supports the minimum set of tls-related
relocations and @modifiers that are necessary to support compiler-
generated code.  This patch extends this to the full set defined
in the ABI (and supported by the GNU assembler) for the benefit
of the assembler parser.

llvm-svn: 184551

[PowerPC] Support @higher et.al. modifiers

This adds support for the @higher, @highera, @highest, and @highesta
modifers, including some missing relocation types.

llvm-svn: 184550

[PowerPC] Support @toc@h modifier

This adds the relocation type and other necessary infrastructure
to use the @toc@h modifier in the assembler.

llvm-svn: 184549

[PowerPC] Support @h modifier

This adds necessary infrastructure to support the @h modifier.
Note that all required relocation types were already present
(and unused).

This patch provides support for using @h in the assembler;
it would also be possible to now use this feature in code
generated by the compiler, but this is not done yet.

llvm-svn: 184548

This is a bit tricky as the xacquire and xrelease hints use the same bytes,
0xf2 and 0xf3, as the repne and rep prefixes.

Fortunately llvm has different llvm MCInst Opcode enums for rep/xrelease
and repne/xacquire. So to make this work a boolean was added the
InternalInstruction struct as part of the Prefix state which is set with the
added logic in readPrefixes() when decoding an instruction to determine
if these prefix bytes are to be disassembled as xacquire or xrelease.  Then
we let the matcher pick the normal prefix instructionID and we change the
Opcode after that when it is set into the MCInst being created.

rdar://11019859

llvm-svn: 184490

The cdp2 instruction should have the same restrictions as cdp on the
co-processor registers.

VFP instructions on v8/AArch32 share the same encoding space as cdp2.

llvm-svn: 184445

[MC] Support @ variants with directional labels

The assembler parser common code supports recognizing symbol variants
using the @ modifer.  On PowerPC, it should also be possible to use
(some of) those modifiers with directional labels, like "1f@l".

This patch adds support for accepting symbol variants on directional
labels as well.

llvm-svn: 184437

[PowerPC] Optimize @ha/@l constructs

This patch adds support for having the assembler optimize fixups
to constructs like "symbol@ha" or "symbol@l" if "symbol" can be
resolved at assembler time.

This optimization is already present in the PPCMCExpr.cpp code
for handling PPC_HA16/PPC_LO16 target expressions.  However,
those target expression were used only on Darwin targets.

This patch changes target expression code so that they are
usable also with the GNU assembler (using the @ha / @l syntax
instead of the ha16() / lo16() syntax), and changes the
MCInst lowering code to generate those target expressions
where appropriate.

It also changes the asm parser to generate HA16/LO16 target
expressions when parsing assembler source that uses the
@ha / @l modifiers.  The effect is that now the above-
mentioned optimization automatically becomes available
for those situations too.
 

llvm-svn: 184436

[PowerPC] Support compare mnemonics with implied CR0

Just like for branch mnemonics (where support was recently added), the
assembler is supposed to support extended mnemonics for the compare
instructions where no condition register is specified explicitly
(and CR0 is assumed implicitly).

This patch adds support for those extended compare mnemonics.


Index: llvm-head/test/MC/PowerPC/ppc64-encoding-ext.s
===================================================================
--- llvm-head.orig/test/MC/PowerPC/ppc64-encoding-ext.s
+++ llvm-head/test/MC/PowerPC/ppc64-encoding-ext.s
@@ -449,21 +449,37 @@
 
 # CHECK: cmpdi 2, 3, 128                 # encoding: [0x2d,0x23,0x00,0x80]
          cmpdi 2, 3, 128
+# CHECK: cmpdi 0, 3, 128                 # encoding: [0x2c,0x23,0x00,0x80]
+         cmpdi 3, 128
 # CHECK: cmpd 2, 3, 4                    # encoding: [0x7d,0x23,0x20,0x00]
          cmpd 2, 3, 4
+# CHECK: cmpd 0, 3, 4                    # encoding: [0x7c,0x23,0x20,0x00]
+         cmpd 3, 4
 # CHECK: cmpldi 2, 3, 128                # encoding: [0x29,0x23,0x00,0x80]
          cmpldi 2, 3, 128
+# CHECK: cmpldi 0, 3, 128                # encoding: [0x28,0x23,0x00,0x80]
+         cmpldi 3, 128
 # CHECK: cmpld 2, 3, 4                   # encoding: [0x7d,0x23,0x20,0x40]
          cmpld 2, 3, 4
+# CHECK: cmpld 0, 3, 4                   # encoding: [0x7c,0x23,0x20,0x40]
+         cmpld 3, 4
 
 # CHECK: cmpwi 2, 3, 128                 # encoding: [0x2d,0x03,0x00,0x80]
          cmpwi 2, 3, 128
+# CHECK: cmpwi 0, 3, 128                 # encoding: [0x2c,0x03,0x00,0x80]
+         cmpwi 3, 128
 # CHECK: cmpw 2, 3, 4                    # encoding: [0x7d,0x03,0x20,0x00]
          cmpw 2, 3, 4
+# CHECK: cmpw 0, 3, 4                    # encoding: [0x7c,0x03,0x20,0x00]
+         cmpw 3, 4
 # CHECK: cmplwi 2, 3, 128                # encoding: [0x29,0x03,0x00,0x80]
          cmplwi 2, 3, 128
+# CHECK: cmplwi 0, 3, 128                # encoding: [0x28,0x03,0x00,0x80]
+         cmplwi 3, 128
 # CHECK: cmplw 2, 3, 4                   # encoding: [0x7d,0x03,0x20,0x40]
          cmplw 2, 3, 4
+# CHECK: cmplw 0, 3, 4                   # encoding: [0x7c,0x03,0x20,0x40]
+         cmplw 3, 4
 
 # FIXME: Trap mnemonics
 
Index: llvm-head/lib/Target/PowerPC/PPCInstrInfo.td
===================================================================
--- llvm-head.orig/lib/Target/PowerPC/PPCInstrInfo.td
+++ llvm-head/lib/Target/PowerPC/PPCInstrInfo.td
@@ -2201,3 +2201,12 @@ defm : BranchExtendedMnemonic<"ne", 68>;
 defm : BranchExtendedMnemonic<"nu", 100>;
 defm : BranchExtendedMnemonic<"ns", 100>;
 
+def : InstAlias<"cmpwi $rA, $imm", (CMPWI CR0, gprc:$rA, s16imm:$imm)>;
+def : InstAlias<"cmpw $rA, $rB", (CMPW CR0, gprc:$rA, gprc:$rB)>;
+def : InstAlias<"cmplwi $rA, $imm", (CMPLWI CR0, gprc:$rA, u16imm:$imm)>;
+def : InstAlias<"cmplw $rA, $rB", (CMPLW CR0, gprc:$rA, gprc:$rB)>;
+def : InstAlias<"cmpdi $rA, $imm", (CMPDI CR0, g8rc:$rA, s16imm:$imm)>;
+def : InstAlias<"cmpd $rA, $rB", (CMPD CR0, g8rc:$rA, g8rc:$rB)>;
+def : InstAlias<"cmpldi $rA, $imm", (CMPLDI CR0, g8rc:$rA, u16imm:$imm)>;
+def : InstAlias<"cmpld $rA, $rB", (CMPLD CR0, g8rc:$rA, g8rc:$rB)>;
+

llvm-svn: 184435

llvm-svn: 184411

[MC/DWARF] Generate multiple .debug_line entries for adjacent .loc directives

The compiler occasionally generates multiple .loc directives in a row
(at the same instruction address).  These need to be transformed into
multple actual .debug_line table entries, since they are used to signal
certain information to the debugger (e.g. if the opening brace of a
function body is on the same line as the declaration).

The MCAsmStreamer version of EmitDwarfLocDirective handles this
correctly by emitting a .loc directive every time it is called.
However, the MCObjectStream version simply defaults to recording
the information and emitting only a single table entry later,
e.g. when EmitInstruction is called.

This patch introduces a MCAsmStreamer::EmitDwarfLocDirective
version that emits a line table entry for a .loc directive
that may already be pending before recording the new directive.
(This is similar to how this is handled in GNU as.)

With this patch (and the code alignment factor patch) applied,
I'm now getting identical DWARF .debug sections for all test-suite
object files on PowerPC for the internal and the external assembler.

llvm-svn: 184357

rdar://14194152

llvm-svn: 184244

"When assembling to the ARM instruction set, the .N qualifier produces
an assembler error and the .W qualifier has no effect."

In the pre-matcher handler in the asm parser the ".w" (wide) qualifier 
when in ARM mode is now discarded. And an error message is now
produced when the ".n" (narrow) qualifier is used in ARM mode.

Test cases for these were added.

rdar://14064574

llvm-svn: 184224

When producing objects that are abi compliant we are 
marking neither the object file nor the assembly file
correctly and thus generate warnings. 

We need to set the EF_CPIC flag in the ELF header when
generating direct object.

Note that the warning is only generated when compiling without PIC.

When compiling with clang the warning will be suppressed by supplying:

 -Wa,-mno-shared -Wa,-call_nonpic

Also the following directive should also be added:

	.option	pic0

when compiling without PIC,  This eliminates the need for supplying:

  -mno-shared -call_nonpic

on the assembler command line.

Patch by Douglas Gilmore

llvm-svn: 184220

For decoding, keep the current behavior of always decoding these as their REP
versions. In the future, this could be improved to recognize the cases where
these behave as XACQUIRE and XRELEASE and decode them as such.

llvm-svn: 184207

When using a positive offset, literal loads where encoded
as if it was negative, because:
- The sign bit was not assigned to an operand
- The addrmode_imm12 operand was not encoding the sign bit correctly

This patch also makes the assembler look at the .w/.n specifier for
loads.

llvm-svn: 184182

llvm-svn: 184181

This fixes two previous issues:
- Negative offsets were not correctly disassembled
- The decoded opcodes were not the right one

llvm-svn: 184180

llvm-svn: 184179

llvm-objdump should provide some way of printing out the addends present in the
.rela sections for debugging purposes if nothing else.

llvm-svn: 184072

was        stc2 p0, c0, [r0]!
instead of stc2 p0, c0, [r0,#0]!

llvm-svn: 183975

llvm-svn: 183914

llvm-svn: 183913

llvm-svn: 183907

[MC/DWARF] Support .debug_frame / .debug_line code alignment factors

I've been comparing the object file output of LLVM's integrated
assembler against the external assembler on PowerPC, and one
area where differences still remain are in DWARF sections.

In particular, the GNU assembler generates .debug_frame and
.debug_line sections using a code alignment factor of 4, since
all PowerPC instructions have size 4 and must be aligned to a
multiple of 4.  However, current MC code hard-codes a code
alignment factor of 1.

This patch changes this by adding a "minimum instruction alignment"
data element to MCAsmInfo and using this as code alignment factor.

This requires passing a MCContext into MCDwarfLineAddr::Encode
and MCDwarfLineAddr::EncodeAdvanceLoc.  Note that one caller,
MCDwarfLineAddr::Write, didn't actually have that information
available.  However, it turns out that this routine is in fact
never used in the whole code base, so the patch simply removes
it.  If it turns out to be needed again at a later time, it
could be re-added with an updated interface.

llvm-svn: 183834