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

http://b/26987366

(cherry picked from commit f3ef5332fa3f4d5ec72c178a2b19dac363a19383)

Change-Id: Ic75dcb63191d65df1b69724576392c0aaeb47728
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.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/PPCELFObjectWriter.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/PPCELFObjectWriter.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/PPCELFObjectWriter.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/PPCELFObjectWriter.cpp
36b56886974eae4f9c5ebc96befd3e7bfe5de338 24-Apr-2014 Stephen Hines <srhines@google.com> Update to LLVM 3.5a.

Change-Id: Ifadecab779f128e62e430c2b4f6ddd84953ed617
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
7a34599db017a5486cf7cd11eb124984acec8286 09-Jul-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Revert r185476 and fix up TLS variant kinds

In the commit message to r185476 I wrote:

>The PowerPC-specific modifiers VK_PPC_TLSGD and VK_PPC_TLSLD
>correspond exactly to the generic modifiers VK_TLSGD and VK_TLSLD.
>This causes some confusion with the asm parser, since VK_PPC_TLSGD
>is output as @tlsgd, which is then read back in as VK_TLSGD.
>
>To avoid this confusion, this patch removes the PowerPC-specific
>modifiers and uses the generic modifiers throughout. (The only
>drawback is that the generic modifiers are printed in upper case
>while the usual convention on PowerPC is to use lower-case modifiers.
>But this is just a cosmetic issue.)

This was unfortunately incorrect, there is is fact another,
serious drawback to using the default VK_TLSLD/VK_TLSGD
variant kinds: using these causes ELFObjectWriter::RelocNeedsGOT
to return true, which in turn causes the ELFObjectWriter to emit
an undefined reference to _GLOBAL_OFFSET_TABLE_.

This is a problem on powerpc64, because it uses the TOC instead
of the GOT, and the linker does not provide _GLOBAL_OFFSET_TABLE_,
so the symbol remains undefined. This means shared libraries
using TLS built with the integrated assembler are currently
broken.

While the whole RelocNeedsGOT / _GLOBAL_OFFSET_TABLE_ situation
probably ought to be properly fixed at some point, for now I'm
simply reverting the r185476 commit. Now this in turn exposes
the breakage of handling @tlsgd/@tlsld in the asm parser that
this check-in was originally intended to fix.

To avoid this regression, I'm also adding a different fix for
this problem: while common code now parses @tlsgd as VK_TLSGD,
a special hack in the asm parser translates this code to the
platform-specific VK_PPC_TLSGD that the back-end now expects.
While this is not really pretty, it's self-contained and
shouldn't hurt anything else for now. One the underlying
problem is fixed, this hack can be reverted again.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185945 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
457571ed6977f78ca8d30b993fa7e86e2d7ad8d5 05-Jul-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Add some special @got@tprel fixup cases

When a target@got@tprel or target@got@tprel@l symbol variant is used in
a fixup_ppc_half16 (*not* fixup_ppc_half16ds) context, we currently fail,
since the corresponding R_PPC64_GOT_TPREL16 / R_PPC64_GOT_TPREL16_LO
relocation types do not exist.

However, since such symbol variants resolve to GOT offsets which are
always 4-aligned, we can simply instead use the _DS variants of the
relocation types, which *do* exist.

The same applies for the @got@dtprel variants.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185700 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.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/PPCELFObjectWriter.cpp
58fc1f52ce070003acbdfedc85d52ba999a2bd11 02-Jul-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Remove VK_PPC_TLSGD and VK_PPC_TLSLD

The PowerPC-specific modifiers VK_PPC_TLSGD and VK_PPC_TLSLD
correspond exactly to the generic modifiers VK_TLSGD and VK_TLSLD.
This causes some confusion with the asm parser, since VK_PPC_TLSGD
is output as @tlsgd, which is then read back in as VK_TLSGD.

To avoid this confusion, this patch removes the PowerPC-specific
modifiers and uses the generic modifiers throughout. (The only
drawback is that the generic modifiers are printed in upper case
while the usual convention on PowerPC is to use lower-case modifiers.
But this is just a cosmetic issue.)



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185476 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
228e0afcfd0d5f167a95c6ddbec2c6a4a90b6d2b 02-Jul-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Add support for TLS data relocations

This adds support for TLS data relocations and modifiers:
.quad target@dtpmod
.quad target@tprel
.quad target@dtprel
Currently exploited by the asm parser only.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185394 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
222e781d92541017c3a9c5dd40cb52e334cdb86f 01-Jul-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Fix @got references to local symbols

A @got reference must always result in a relocation, so that
the linker has a chance to set up the GOT entry, even if the
symbol happens to be local.

Add a PPCELFObjectWriter::ExplicitRelSym routine that enforces
a relocation to be emitted for GOT references.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185353 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
5de735a962a255676cf3a9bc255579d465670633 25-Jun-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Support @got modifier

Add VK_... values and relocation types necessary to support
the @got family of modifiers. Used by the asm parser only.



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



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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184551 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
f7c1ee79fe90353fcd3f545f9d45a01a837bbf4b 21-Jun-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Support @higher et.al. modifiers

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184550 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
f8f87dcfceadd1b842d130303a7091ad7d7d67d0 21-Jun-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Support @toc@h modifier

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



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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184548 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
92cfa61c50d01307d658753f8d47f4e8555a6fa9 21-Jun-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Rename some more VK_PPC_ enums

This renames more VK_PPC_ enums, to make them more closely reflect
the @modifier string they represent. This also prepares for adding
a bunch of new VK_PPC_ enums in upcoming patches.

For consistency, some MO_ flags related to VK_PPC_ enums are
likewise renamed.

No change in behaviour.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184547 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
846565924a6f2932efc75c249b29c3619e587bbb 21-Jun-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Clean up VK_PPC_TOC... names

This is another minor cleanup; to bring enum names in line
with the corresponding @modifier names, this renames:

VK_PPC_TOC -> VK_PPC_TOCBASE
VK_PPC_TOC_ENTRY -> VK_PPC_TOC16

No code change intended.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184491 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
769accfb4d71caff9152309eaa5e704e065b5846 21-Jun-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Minor cleanup in PPCELFObjectWriter::getRelocTypeInner

This just re-sorts the big switch statement in
PPCELFObjectWriter::getRelocTypeInner to follow
the (numerical) order of the reloc types, and
fixes a couple of whitespace issues.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184485 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
edaa58ee66699b99841ee5dfdd485aedbae3bf90 24-May-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Clean up generation of ha16() / lo16() markers

When targeting the Darwin assembler, we need to generate markers ha16() and
lo16() to designate the high and low parts of a (symbolic) immediate. This
is necessary not just for plain symbols, but also for certain symbolic
expression, typically along the lines of ha16(A - B). The latter doesn't
work when simply using VariantKind flags on the symbol reference.
This is why the current back-end uses hacks (explicitly called out as such
via multiple FIXMEs) in the symbolLo/symbolHi print methods.

This patch uses target-defined MCExpr codes to represent the Darwin
ha16/lo16 constructs, following along the lines of the equivalent solution
used by the ARM back end to handle their :upper16: / :lower16: markers.
This allows us to get rid of special handling both in the symbolLo/symbolHi
print method and in the common code MCExpr::print routine. Instead, the
ha16 / lo16 markers are printed simply in a custom print routine for the
target MCExpr types. (As a result, the symbolLo/symbolHi print methods
can now replaced by a single printS16ImmOperand routine that also handles
symbolic operands.)

The patch also provides a EvaluateAsRelocatableImpl routine to handle
ha16/lo16 constructs. This is not actually used at the moment by any
in-tree code, but is provided as it makes merging into David Fang's
out-of-tree Mach-O object writer simpler.

Since there is no longer any need to treat VK_PPC_GAS_HA16 and
VK_PPC_DARWIN_HA16 differently, they are merged into a single
VK_PPC_ADDR16_HA (and likewise for the _LO16 types).



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182616 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.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/PPCELFObjectWriter.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/PPCELFObjectWriter.cpp
4ef61f2ad4ff509ee05c7051d359009511f81226 15-May-2013 Rafael Espindola <rafael.espindola@gmail.com> Cleanup relocation sorting for ELF.

We want the order to be deterministic on all platforms. NAKAMURA Takumi
fixed that in r181864. This patch is just two small cleanups:

* Move the function to the cpp file. It is only passed to array_pod_sort.
* Remove the ppc implementation which is now redundant

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181910 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.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/PPCELFObjectWriter.cpp
a3967b6844f4be588c724ada3692e734bba65cf1 08-May-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> [PowerPC] Fix regression in generating @ha/@l relocs

The patch I committed as revision 167864 introduced a regression that
causes LLVM to no longer generate appropriate relocs for @ha/@l symbol
references (but fail an assertion instead).

This is fixed here by re-enabling support for the VK_PPC_GAS_HA16/
VK_PPC_GAS_LO16 variant kinds (and their Darwin variants) in
PPCELFObjectWriter.cpp.

Tested by running projects/test-suite in -m32 mode with the integrated
assembler forced on. A standalone test case will be committed shortly
as well.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181450 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
8ade90930863acf94fbb2ccd91acefcf114c1f3e 26-Apr-2013 Ulrich Weigand <ulrich.weigand@de.ibm.com> PowerPC: Support PC-relative fixup_ppc_brcond14.

When testing the asm parser, I ran into an error when using a conditional
branch to an external symbol (this doesn't occur in compiler-generated
code) due to missing support in PPCELFObjectWriter::getRelocTypeInner.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180605 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.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/PPCELFObjectWriter.cpp
fc7695a653323071ec141aee994e4188592ad1f5 25-Feb-2013 Bill Schmidt <wschmidt@linux.vnet.ibm.com> Fix missing relocation for TLS addressing peephole optimization.

Report and fix due to Kai Nacke. Testcase update by me.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176029 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
06ab2c828a5605abec36eb0d6749940fa6eb7391 21-Feb-2013 Bill Schmidt <wschmidt@linux.vnet.ibm.com> Relocation enablement for PPC DAG postprocessing pass

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175693 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
7b449889e7886b263718b5103538970f287bc37e 04-Jan-2013 Adhemerval Zanella <azanella@linux.vnet.ibm.com> PowerPC: Fix eh_frame relocation for PIC

This patch fixes the PPC eh_frame definitions for the personality and
frame unwinding for PIC objects. It makes PIC build correctly creates
relative relocations in the '.rela.eh_frame' segments and thus avoiding
a text relocation that generates a DT_TEXTREL segments in link phase.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171506 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
d3eb4f46f011f5880e09862559c17f03e38bef39 14-Dec-2012 Bill Schmidt <wschmidt@linux.vnet.ibm.com> This patch removes some nondeterminism from direct object file output
for TLS dynamic models on 64-bit PowerPC ELF. The default sort routine
for relocations only sorts on the r_offset field; but with TLS, there
can be two relocations with the same r_offset. For PowerPC, this patch
sorts secondarily on descending r_type, which matches the behavior
expected by the linker.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170237 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
b453e16855f347e300f1dc0cd0dfbdd65c27b0d2 14-Dec-2012 Bill Schmidt <wschmidt@linux.vnet.ibm.com> This patch improves the 64-bit PowerPC InitialExec TLS support by providing
for a wider range of GOT entries that can hold thread-relative offsets.
This matches the behavior of GCC, which was not documented in the PPC64 TLS
ABI. The ABI will be updated with the new code sequence.

Former sequence:

ld 9,x@got@tprel(2)
add 9,9,x@tls

New sequence:

addis 9,2,x@got@tprel@ha
ld 9,x@got@tprel@l(9)
add 9,9,x@tls

Note that a linker optimization exists to transform the new sequence into
the shorter sequence when appropriate, by replacing the addis with a nop
and modifying the base register and relocation type of the ld.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170209 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.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/PPCELFObjectWriter.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/PPCELFObjectWriter.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/PPCELFObjectWriter.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/PPCELFObjectWriter.cpp
34a9d4b3b9b7858b729a1af67afa721c048fe5e7 27-Nov-2012 Bill Schmidt <wschmidt@linux.vnet.ibm.com> This patch implements medium code model support for 64-bit PowerPC.

The default for 64-bit PowerPC is small code model, in which TOC entries
must be addressable using a 16-bit offset from the TOC pointer. Additionally,
only TOC entries are addressed via the TOC pointer.

With medium code model, TOC entries and data sections can all be addressed
via the TOC pointer using a 32-bit offset. Cooperation with the linker
allows 16-bit offsets to be used when these are sufficient, reducing the
number of extra instructions that need to be executed. Medium code model
also does not generate explicit TOC entries in ".section toc" for variables
that are wholly internal to the compilation unit.

Consider a load of an external 4-byte integer. With small code model, the
compiler generates:

ld 3, .LC1@toc(2)
lwz 4, 0(3)

.section .toc,"aw",@progbits
.LC1:
.tc ei[TC],ei

With medium model, it instead generates:

addis 3, 2, .LC1@toc@ha
ld 3, .LC1@toc@l(3)
lwz 4, 0(3)

.section .toc,"aw",@progbits
.LC1:
.tc ei[TC],ei

Here .LC1@toc@ha is a relocation requesting the upper 16 bits of the
32-bit offset of ei's TOC entry from the TOC base pointer. Similarly,
.LC1@toc@l is a relocation requesting the lower 16 bits. Note that if
the linker determines that ei's TOC entry is within a 16-bit offset of
the TOC base pointer, it will replace the "addis" with a "nop", and
replace the "ld" with the identical "ld" instruction from the small
code model example.

Consider next a load of a function-scope static integer. For small code
model, the compiler generates:

ld 3, .LC1@toc(2)
lwz 4, 0(3)

.section .toc,"aw",@progbits
.LC1:
.tc test_fn_static.si[TC],test_fn_static.si
.type test_fn_static.si,@object
.local test_fn_static.si
.comm test_fn_static.si,4,4

For medium code model, the compiler generates:

addis 3, 2, test_fn_static.si@toc@ha
addi 3, 3, test_fn_static.si@toc@l
lwz 4, 0(3)

.type test_fn_static.si,@object
.local test_fn_static.si
.comm test_fn_static.si,4,4

Again, the linker may replace the "addis" with a "nop", calculating only
a 16-bit offset when this is sufficient.

Note that it would be more efficient for the compiler to generate:

addis 3, 2, test_fn_static.si@toc@ha
lwz 4, test_fn_static.si@toc@l(3)

The current patch does not perform this optimization yet. This will be
addressed as a peephole optimization in a later patch.

For the moment, the default code model for 64-bit PowerPC will remain the
small code model. We plan to eventually change the default to medium code
model, which matches current upstream GCC behavior. Note that the different
code models are ABI-compatible, so code compiled with different models will
be linked and execute correctly.

I've tested the regression suite and the application/benchmark test suite in
two ways: Once with the patch as submitted here, and once with additional
logic to force medium code model as the default. The tests all compile
cleanly, with one exception. The mandel-2 application test fails due to an
unrelated ABI compatibility with passing complex numbers. It just so happens
that small code model was incredibly lucky, in that temporary values in
floating-point registers held the expected values needed by the external
library routine that was called incorrectly. My current thought is to correct
the ABI problems with _Complex before making medium code model the default,
to avoid introducing this "regression."

Here are a few comments on how the patch works, since the selection code
can be difficult to follow:

The existing logic for small code model defines three pseudo-instructions:
LDtoc for most uses, LDtocJTI for jump table addresses, and LDtocCPT for
constant pool addresses. These are expanded by SelectCodeCommon(). The
pseudo-instruction approach doesn't work for medium code model, because
we need to generate two instructions when we match the same pattern.
Instead, new logic in PPCDAGToDAGISel::Select() intercepts the TOC_ENTRY
node for medium code model, and generates an ADDIStocHA followed by either
a LDtocL or an ADDItocL. These new node types correspond naturally to
the sequences described above.

The addis/ld sequence is generated for the following cases:
* Jump table addresses
* Function addresses
* External global variables
* Tentative definitions of global variables (common linkage)

The addis/addi sequence is generated for the following cases:
* Constant pool entries
* File-scope static global variables
* Function-scope static variables

Expanding to the two-instruction sequences at select time exposes the
instructions to subsequent optimization, particularly scheduling.

The rest of the processing occurs at assembly time, in
PPCAsmPrinter::EmitInstruction. Each of the instructions is converted to
a "real" PowerPC instruction. When a TOC entry needs to be created, this
is done here in the same manner as for the existing LDtoc, LDtocJTI, and
LDtocCPT pseudo-instructions (I factored out a new routine to handle this).

I had originally thought that if a TOC entry was needed for LDtocL or
ADDItocL, it would already have been generated for the previous ADDIStocHA.
However, at higher optimization levels, the ADDIStocHA may appear in a
different block, which may be assembled textually following the block
containing the LDtocL or ADDItocL. So it is necessary to include the
possibility of creating a new TOC entry for those two instructions.

Note that for LDtocL, we generate a new form of LD called LDrs. This
allows specifying the @toc@l relocation for the offset field of the LD
instruction (i.e., the offset is replaced by a SymbolLo relocation).
When the peephole optimization described above is added, we will need
to do similar things for all immediate-form load and store operations.

The seven "mcm-n.ll" test cases are kept separate because otherwise the
intermingling of various TOC entries and so forth makes the tests fragile
and hard to understand.

The above assumes use of an external assembler. For use of the
integrated assembler, new relocations are added and used by
PPCELFObjectWriter. Testing is done with "mcm-obj.ll", which tests for
proper generation of the various relocations for the same sequences
tested with the external assembler.






git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168708 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
ba6086818d9c5070061f74ac9944666b4312c6f0 13-Nov-2012 Ulrich Weigand <ulrich.weigand@de.ibm.com> Add (some) PowerPC TLS relocation types to ELF.h and
generate them from PPCELFObjectWriter::getRelocTypeInner
as appropriate.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167864 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.cpp
18560fae0bb122857a61bb36f22628901cdc3dde 25-Oct-2012 Adhemerval Zanella <azanella@linux.vnet.ibm.com> This patch fixes the MC object emission of 'nop' for external function calls
and also fixes the R_PPC64_TOC16 and R_PPC64_TOC16_DS relocation offset.
The 'nop' is needed so a restore TOC instruction (ld r2,40(r1)) can be placed
by the linker to correct restore the TOC of previous function.

Current code has two issues: it defines in PPCInstr64Bit.td file a LDinto_toc
and LDtoc_restore as a DSForm_1 with DS_RA=0 where it should be
DS=2 (the 8 bytes displacement of the TOC saving). It also wrongly emits a
MC intruction using an uint32_t value while the PPC::BL8_NOP_ELF
and PPC::BLA8_NOP_ELF are both uint64_t (because of the following 'nop').

This patch corrects the remaining ExecutionEngine using MCJIT:

ExecutionEngine/2002-12-16-ArgTest.ll
ExecutionEngine/2003-05-07-ArgumentTest.ll
ExecutionEngine/2005-12-02-TailCallBug.ll
ExecutionEngine/hello.ll
ExecutionEngine/hello2.ll
ExecutionEngine/test-call.ll



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166682 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/PowerPC/MCTargetDesc/PPCELFObjectWriter.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/PPCELFObjectWriter.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/PPCELFObjectWriter.cpp
f3a86fb03d196994dc7923351f15d8ed9343013e 22-Dec-2011 Rafael Espindola <rafael.espindola@gmail.com> Move PPC bits to lib/Target/PowerPC.

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