History log of /external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
de2d8694e25a814696358e95141f4b1aa4d8847e 20-Sep-2016 Pirama Arumuga Nainar <pirama@google.com> Update aosp/master LLVM for rebase to r275480

Bug: http://b/31320715

This merges commit 7dcf7f03e005379ef2f06db96aa93f06186b66d5 from
aosp/dev.

Test: Build AOSP and run RenderScript tests (host tests for slang and
libbcc, RsTest, CTS)

Change-Id: Iaf3738f74312d875e69f61d604ac058f381a2a1a
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
6948897e478cbd66626159776a8017b3c18579b9 01-Jul-2015 Pirama Arumuga Nainar <pirama@google.com> Update aosp/master LLVM for rebase to r239765

Bug: 20140355: This rebase pulls the upstream fix for the spurious
warnings mentioned in the bug.

Change-Id: I7fd24253c50f4d48d900875dcf43ce3f1721a3da
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
0c7f116bb6950ef819323d855415b2f2b0aad987 06-May-2015 Pirama Arumuga Nainar <pirama@google.com> Update aosp/master LLVM for rebase to r235153

Change-Id: I9bf53792f9fc30570e81a8d80d296c681d005ea7
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
ebe69fe11e48d322045d5949c83283927a0d790b 23-Mar-2015 Stephen Hines <srhines@google.com> Update aosp/master LLVM for rebase to r230699.

Change-Id: I2b5be30509658cb8266be782de0ab24f9099f9b9
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
37ed9c199ca639565f6ce88105f9e39e898d82d0 01-Dec-2014 Stephen Hines <srhines@google.com> Update aosp/master LLVM for rebase to r222494.

Change-Id: Ic787f5e0124df789bd26f3f24680f45e678eef2d
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
dce4a407a24b04eebc6a376f8e62b41aaa7b071f 29-May-2014 Stephen Hines <srhines@google.com> Update LLVM for 3.5 rebase (r209712).

Change-Id: I149556c940fb7dc92d075273c87ff584f400941f
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
36b56886974eae4f9c5ebc96befd3e7bfe5de338 24-Apr-2014 Stephen Hines <srhines@google.com> Update to LLVM 3.5a.

Change-Id: Ifadecab779f128e62e430c2b4f6ddd84953ed617
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
9637da60835a60f8ccd8289d04c60b2dcd4b9b5a 26-Sep-2013 David Majnemer <david.majnemer@gmail.com> PPC: Allow partial fills in writeNopData()

When asked to pad an irregular number of bytes, we should fill with
zeros. This is consistent with the behavior specified in the AIX
Assembler Language Reference as well as other LLVM and binutils
assemblers.

N.B. There is a small deviation from binutils' PPC assembler:
when handling pads which are greater than 4 bytes but not mod 4,
binutils will not emit any NOP sequences at all and only use zeros.
This may or may not be a bug but there is no excellent rationale as to
why that behavior is important to emulate. If that behavior is needed,
we can change writeNopData() to behave in the same way.

This fixes PR17352.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191426 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
c3cee57f7d20f69a84fd88464ed8cf050e63c7ad 09-Sep-2013 Bill Wendling <isanbard@gmail.com> Generate compact unwind encoding from CFI directives.

We used to generate the compact unwind encoding from the machine
instructions. However, this had the problem that if the user used `-save-temps'
or compiled their hand-written `.s' file (with CFI directives), we wouldn't
generate the compact unwind encoding.

Move the algorithm that generates the compact unwind encoding into the
MCAsmBackend. This way we can generate the encoding whether the code is from a
`.ll' or `.s' file.

<rdar://problem/13623355>


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190290 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
5510728d28bb1ee04abc32da3d21b7df12948053 01-Sep-2013 Charles Davis <cdavis5x@gmail.com> Move everything depending on Object/MachOFormat.h over to Support/MachO.h.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189728 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
f69a29b23a116a3520f185054290c445abf9aa62 27-Aug-2013 Charles Davis <cdavis5x@gmail.com> 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189321 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
9c3dd1b0d1e96ef408b68da3b06c6ebd6c943601 27-Aug-2013 Charles Davis <cdavis5x@gmail.com> Move everything depending on Object/MachOFormat.h over to Support/MachO.h.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189315 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
d4f9d05fde4b2cfd202a5852ec1ec3e960ef53ed 08-Aug-2013 David Fang <fang@csl.cornell.edu> initial draft of PPCMachObjectWriter.cpp
this records relocation entries in the mach-o object file
for PIC code generation.
tested on powerpc-darwin8, validated against darwin otool -rvV

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188004 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
f38cc38fa647d4e72c053c39bbe0cdec1342535f 26-Jul-2013 Bill Schmidt <wschmidt@linux.vnet.ibm.com> [PowerPC] Support powerpc64le as a syntax-checking target.

This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code. Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing. Code generation will otherwise be the same as
powerpc64 (big-endian), for now.

The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.

The LLVM portions of this patch simply add ppc64le coverage everywhere
that ppc64 coverage currently exists. There is nothing of any import
worth testing until such time as little-endian code generation is
implemented. In the corresponding Clang patch, there is a new test
case variant to ensure that correct built-in defines for little-endian
code are generated.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187179 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
23a72c8f7e46618ff8dbdbba4e8c1a2c4e44e3df 05-Jul-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Support @tls in the asm parser

This adds support for the last missing construct to parse TLS-related
assembler code:
add 3, 4, symbol@tls

The ADD8TLS currently hard-codes the @tls into the assembler string.
This cannot be handled by the asm parser, since @tls is parsed as
a symbol variant. This patch changes ADD8TLS to have the @tls suffix
printed as symbol variant on output too, which allows us to remove
the isCodeGenOnly marker from ADD8TLS. This in turn means that we
can add a AsmOperand to accept @tls marked symbols on input.

As a side effect, this means that the fixup_ppc_tlsreg fixup type
is no longer necessary and can be merged into fixup_ppc_nofixup.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185692 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
972befb3f281f0f9ce08d7cf27b4e879327676b0 04-Jul-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Implement writeNopData

This implements a proper PPCAsmBackend::writeNopData routine
that actually writes PowerPC nop instructions.

This fixes the last remaining difference in object file output
(text section) between the integrated assembler and GNU as
that I've seen anywhere.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185662 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
9679c47a07386cbf3547a0927609c7ee080b2aab 24-Jun-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [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.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184721 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
e152eac63efa836cbb109d79e4307516fa16f1a6 17-May-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Merge/rename PPC fixup types

Now that fixup_ppc_ha16 and fixup_ppc_lo16 are being treated exactly
the same everywhere, it no longer makes sense to have two fixup types.

This patch merges them both into a single type fixup_ppc_half16,
and renames fixup_ppc_lo16_ds to fixup_ppc_half16ds for consistency.
(The half16 and half16ds names are taken from the description of
relocation types in the PowerPC ABI.)

No change in code generation expected.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182092 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
c299ad32c8e59ceea05ede15e1c59ac787d17feb 17-May-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Fix processing of ha16/lo16 fixups

The current PowerPC MC back end distinguishes between fixup_ppc_ha16
and fixup_ppc_lo16, which are determined by the instruction the fixup
applies to, and uses this distinction to decide whether a fixup ought
to resolve to the high or the low part of a symbol address.

This isn't quite correct, however. It is valid -if unusual- assembler
to use, e.g.
li 1, symbol@ha
or
lis 1, symbol@l
Whether the high or the low part of the address is used depends solely
on the @ suffix, not on the instruction.

In addition, both
li 1, symbol
and
lis 1, symbol
are valid, assuming the symbol address fits into 16 bits; again, both
will then refer to the actual symbol value (so li will load the value
itself, while lis will load the value shifted by 16).


To fix this, two places need to be adapted. If the fixup cannot be
resolved at assembler time, a relocation needs to be emitted via
PPCELFObjectWriter::getRelocType. This routine already looks at
the VK_ type to determine the relocation. The only problem is that
will reject any _LO modifier in a ha16 fixup and vice versa. This
is simply incorrect; any of those modifiers ought to be accepted
for either fixup type.

If the fixup *can* be resolved at assembler time, adjustFixupValue
currently selects the high bits of the symbol value if the fixup
type is ha16. Again, this is incorrect; see the above example
lis 1, symbol

Now, in theory we'd have to respect a VK_ modifier here. However,
in fact common code never even attempts to resolve symbol references
using any nontrivial VK_ modifier at assembler time; it will always
fall back to emitting a reloc and letting the linker handle it.

If this ever changes, presumably there'd have to be a target callback
to resolve VK_ modifiers. We'd then have to handle @ha etc. there.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182091 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
9122396a4dea52cf917062782fc2f39c7dc698bb 15-May-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Remove need for adjustFixupOffst hack

Now that applyFixup understands differently-sized fixups, we can define
fixup_ppc_lo16/fixup_ppc_lo16_ds/fixup_ppc_ha16 to properly be 2-byte
fixups, applied at an offset of 2 relative to the start of the
instruction text.

This has the benefit that if we actually need to generate a real
relocation record, its address will come out correctly automatically,
without having to fiddle with the offset in adjustFixupOffset.

Tested on both 64-bit and 32-bit PowerPC, using external and
integrated assembler.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181894 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
b1cf8de85af10ff3d4ded6431be1cebd6133fd54 15-May-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Correctly handle fixups of other than 4 byte size

The PPCAsmBackend::applyFixup routine handles the case where a
fixup can be resolved within the same object file. However,
this routine is currently hard-coded to assume the size of
any fixup is always exactly 4 bytes.

This is sort-of correct for fixups on instruction text; even
though it only works because several of what really would be
2-byte fixups are presented as 4-byte fixups instead (requiring
another hack in PPCELFObjectWriter::adjustFixupOffset to clean
it up).

However, this assumption breaks down completely for fixups
on data, which legitimately can be of any size (1, 2, 4, or 8).

This patch makes applyFixup aware of fixups of varying sizes,
introducing a new helper routine getFixupKindNumBytes (along
the lines of what the ARM back end does). Note that in order
to handle fixups of size 8, we also need to fix the return type
of adjustFixupValue to uint64_t to avoid truncation.

Tested on both 64-bit and 32-bit PowerPC, using external and
integrated assembler.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181891 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
65e90c036472380bba160c349412f37128608e1c 26-Mar-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> PowerPC: Simplify handling of fixups.

MCTargetDesc/PPCMCCodeEmitter.cpp current has code like:

if (isSVR4ABI() && is64BitMode())
Fixups.push_back(MCFixup::Create(0, MO.getExpr(),
(MCFixupKind)PPC::fixup_ppc_toc16));
else
Fixups.push_back(MCFixup::Create(0, MO.getExpr(),
(MCFixupKind)PPC::fixup_ppc_lo16));

This is a problem for the asm parser, since it requires knowledge of
the ABI / 64-bit mode to be set up. However, more fundamentally,
at this point we shouldn't make such distinctions anyway; in an assembler
file, it always ought to be possible to e.g. generate TOC relocations even
when the main ABI is one that doesn't use TOC.

Fortunately, this is actually completely unnecessary; that code was added
to decide whether to generate TOC relocations, but that information is in
fact already encoded in the VariantKind of the underlying symbol.

This commit therefore merges those fixup types into one, and then decides
which relocation to use based on the VariantKind.

No changes in generated code.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178007 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
251040bc18eedfa56d01fe92836e55cfd8c5d990 08-Jan-2013 Eli Bendersky <eliben@google.com> Renamed MCInstFragment to MCRelaxableFragment and added some comments.

No change in functionality.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171822 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
349c2787cf9e174c8aa955bf8e3b09a405b2aece 12-Dec-2012 Bill Schmidt <wschmidt@linux.vnet.ibm.com> This patch implements local-dynamic TLS model support for the 64-bit
PowerPC target. This is the last of the four models, so we now have
full TLS support.

This is mostly a straightforward extension of the general dynamic model.
I had to use an additional Chain operand to tie ADDIS_DTPREL_HA to the
register copy following ADDI_TLSLD_L; otherwise everything above the
ADDIS_DTPREL_HA appeared dead and was removed.

As before, there are new test cases to test the assembly generation, and
the relocations output during integrated assembly. The expected code
gen sequence can be read in test/CodeGen/PowerPC/tls-ld.ll.

There are a couple of things I think can be done more efficiently in the
overall TLS code, so there will likely be a clean-up patch forthcoming;
but for now I want to be sure the functionality is in place.

Bill


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170003 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
57ac1f458a754f30cf500410b438fb260f9b8fe5 11-Dec-2012 Bill Schmidt <wschmidt@linux.vnet.ibm.com> This patch implements the general dynamic TLS model for 64-bit PowerPC.

Given a thread-local symbol x with global-dynamic access, the generated
code to obtain x's address is:

Instruction Relocation Symbol
addis ra,r2,x@got@tlsgd@ha R_PPC64_GOT_TLSGD16_HA x
addi r3,ra,x@got@tlsgd@l R_PPC64_GOT_TLSGD16_L x
bl __tls_get_addr(x@tlsgd) R_PPC64_TLSGD x
R_PPC64_REL24 __tls_get_addr
nop
<use address in r3>

The implementation borrows from the medium code model work for introducing
special forms of ADDIS and ADDI into the DAG representation. This is made
slightly more complicated by having to introduce a call to the external
function __tls_get_addr. Using the full call machinery is overkill and,
more importantly, makes it difficult to add a special relocation. So I've
introduced another opcode GET_TLS_ADDR to represent the function call, and
surrounded it with register copies to set up the parameter and return value.

Most of the code is pretty straightforward. I ran into one peculiarity
when I introduced a new PPC opcode BL8_NOP_ELF_TLSGD, which is just like
BL8_NOP_ELF except that it takes another parameter to represent the symbol
("x" above) that requires a relocation on the call. Something in the
TblGen machinery causes BL8_NOP_ELF and BL8_NOP_ELF_TLSGD to be treated
identically during the emit phase, so this second operand was never
visited to generate relocations. This is the reason for the slightly
messy workaround in PPCMCCodeEmitter.cpp:getDirectBrEncoding().

Two new tests are included to demonstrate correct external assembly and
correct generation of relocations using the integrated assembler.

Comments welcome!

Thanks,
Bill


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169910 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
d7802bf0ddcac16ee910105922492aee86a53e1b 04-Dec-2012 Bill Schmidt <wschmidt@linux.vnet.ibm.com> This patch introduces initial-exec model support for thread-local storage
on 64-bit PowerPC ELF.

The patch includes code to handle external assembly and MC output with the
integrated assembler. It intentionally does not support the "old" JIT.

For the initial-exec TLS model, the ABI requires the following to calculate
the address of external thread-local variable x:

Code sequence Relocation Symbol
ld 9,x@got@tprel(2) R_PPC64_GOT_TPREL16_DS x
add 9,9,x@tls R_PPC64_TLS x

The register 9 is arbitrary here. The linker will replace x@got@tprel
with the offset relative to the thread pointer to the generated GOT
entry for symbol x. It will replace x@tls with the thread-pointer
register (13).

The two test cases verify correct assembly output and relocation output
as just described.

PowerPC-specific selection node variants are added for the two
instructions above: LD_GOT_TPREL and ADD_TLS. These are inserted
when an initial-exec global variable is encountered by
PPCTargetLowering::LowerGlobalTLSAddress(), and later lowered to
machine instructions LDgotTPREL and ADD8TLS. LDgotTPREL is a pseudo
that uses the same LDrs support added for medium code model's LDtocL,
with a different relocation type.

The rest of the processing is straightforward.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169281 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
d04a8d4b33ff316ca4cf961e06c9e312eff8e64f 03-Dec-2012 Chandler Carruth <chandlerc@gmail.com> Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
d3022b894691017169ff0681c6bea18725330cd1 24-Nov-2012 Benjamin Kramer <benny.kra@googlemail.com> PPC: Reinstate the fatal error when trying to emit a macho file.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168543 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
e8ca482c9734a556f3b66d44ba27e23a1d00b1e0 24-Nov-2012 Benjamin Kramer <benny.kra@googlemail.com> PPC: Share applyFixup between ELF and Darwin.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168540 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
aa71428378c1cb491ca60041d8ba7aa110bc963d 25-Oct-2012 Adhemerval Zanella <azanella@linux.vnet.ibm.com> Initial TOC support for PowerPC64 object creation

This patch adds initial PPC64 TOC MC object creation using the small mcmodel
(a single 64K TOC) adding the some TOC relocations (R_PPC64_TOC,
R_PPC64_TOC16, and R_PPC64_TOC16DS).

The addition of 'undefinedExplicitRelSym' hook on 'MCELFObjectTargetWriter'
is meant to avoid the creation of an unreferenced ".TOC." symbol (used in
the .odp creation) as well to set the R_PPC64_TOC relocation target as the
temporary ".TOC." symbol. On PPC64 ABI, the R_PPC64_TOC relocation should
not point to any symbol.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166677 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
536a88ad5bf160232205192a7ce72e50bfadbded 18-Sep-2012 Roman Divacky <rdivacky@freebsd.org> When creating MCAsmBackend pass the CPU string as well. In X86AsmBackend
store this and use it to not emit long nops when the CPU is geode which
doesnt support them.

Fixes PR11212.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164132 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
05b2bc8781d9af403a257599613e12cb8fef19e8 16-Aug-2012 Roman Divacky <rdivacky@freebsd.org> Revert r162034, r162035 and r162037.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162039 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
e88d17de99c5f46bc8104bc777f657d0299fd0e6 16-Aug-2012 Roman Divacky <rdivacky@freebsd.org> Define and handle additional fixup kinds. By Adhemerval Zanella.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162037 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
f1d0f7781e766df878bec4e7977fa3204374f394 26-Mar-2012 Craig Topper <craig.topper@gmail.com> Prune some includes and forward declarations.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153429 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
79aa3417eb6f58d668aadfedf075240a41d35a26 17-Mar-2012 Craig Topper <craig.topper@gmail.com> Reorder includes in Target backends to following coding standards. Remove some superfluous forward declarations.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152997 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
bc2198133a1836598b54b943420748e75d5dea94 07-Feb-2012 Craig Topper <craig.topper@gmail.com> Convert assert(0) to llvm_unreachable

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149961 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
bc3af9b618c061294c7df00f3313f9c5234b8450 18-Jan-2012 Jim Grosbach <grosbach@apple.com> Tidy up. 80 columns.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148401 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
ec3433852dd11e8ff60c9610b4c84468e5935f2b 18-Jan-2012 Jim Grosbach <grosbach@apple.com> Tidy up. MCAsmBackend naming conventions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148400 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
f51e95a9f2ce10ca0eb8a353e1fc1d9d49ec130c 22-Dec-2011 Rafael Espindola <rafael.espindola@gmail.com> Fix an incomplete refactoring of the ppc backend. Thanks to rdivacky for reporting
it. It does need some some tests...

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147154 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
dc9a8a378daf432d8dcfc178507afe149706f9a6 21-Dec-2011 Rafael Espindola <rafael.espindola@gmail.com> Reduce the exposure of Triple::OSType in the ELF object writer. This will
avoid including ADT/Triple.h in many places when the target specific bits are
moved.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147059 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
6482e9114954def43fc08e83aadec1aadfc64200 06-Dec-2011 NAKAMURA Takumi <geek4civic@gmail.com> MipsAsmBackend.cpp, PPCAsmBackend.cpp: Fix -Asserts build to appease msvc.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145894 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
370b78d795154899a22ca2b4674e890661ff1d59 06-Dec-2011 Jim Grosbach <grosbach@apple.com> Move target-specific logic out of generic MCAssembler.

Whether a fixup needs relaxation for the associated instruction is a
target-specific function, as the FIXME indicated. Create a hook for that
and use it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145881 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
3e74d6fdd248e20a280f1dff3da9a6c689c2c4c3 24-Aug-2011 Evan Cheng <evan.cheng@apple.com> Move TargetRegistry and TargetSelect from Target to Support where they belong.
These are strictly utilities for registering targets and components.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138450 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
2c0d69fad0e658117922f3d96d9b732bedf9fd47 02-Aug-2011 Roman Divacky <rdivacky@freebsd.org> Sketch out PowerPC ELF writer. This is enough to get clang -integrated-as
to compile a working hello world on FreeBSD/PPC32.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136689 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
78c10eeaa57d1c6c4b7781d3c0bcb0cfbbc43b5c 26-Jul-2011 Evan Cheng <evan.cheng@apple.com> Rename TargetAsmBackend to MCAsmBackend; rename createAsmBackend to createMCAsmBackend.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136010 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
966aeb5788c242cfaca35c56c0ddc0ff778d4376 25-Jul-2011 Evan Cheng <evan.cheng@apple.com> Refactor PPC target to separate MC routines from Target routines.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135942 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp