History log of /external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
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