2010-11-15 05:57:53 +00:00
|
|
|
//===-- PPCFixupKinds.h - PPC Specific Fixup Entries ------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef LLVM_PPC_PPCFIXUPKINDS_H
|
|
|
|
#define LLVM_PPC_PPCFIXUPKINDS_H
|
|
|
|
|
|
|
|
#include "llvm/MC/MCFixup.h"
|
|
|
|
|
2013-03-17 12:40:42 +00:00
|
|
|
#undef PPC
|
|
|
|
|
2010-11-15 05:57:53 +00:00
|
|
|
namespace llvm {
|
|
|
|
namespace PPC {
|
|
|
|
enum Fixups {
|
2010-11-15 06:12:22 +00:00
|
|
|
// fixup_ppc_br24 - 24-bit PC relative relocation for direct branches like 'b'
|
|
|
|
// and 'bl'.
|
2010-11-15 05:57:53 +00:00
|
|
|
fixup_ppc_br24 = FirstTargetFixupKind,
|
|
|
|
|
2010-11-15 06:12:22 +00:00
|
|
|
/// fixup_ppc_brcond14 - 14-bit PC relative relocation for conditional
|
|
|
|
/// branches.
|
|
|
|
fixup_ppc_brcond14,
|
|
|
|
|
2013-05-17 12:37:21 +00:00
|
|
|
/// fixup_ppc_half16 - A 16-bit fixup corresponding to lo16(_foo)
|
|
|
|
/// or ha16(_foo) for instrs like 'li' or 'addis'.
|
|
|
|
fixup_ppc_half16,
|
2010-11-15 06:33:39 +00:00
|
|
|
|
2013-05-17 12:37:21 +00:00
|
|
|
/// fixup_ppc_half16ds - A 14-bit fixup corresponding to lo16(_foo) with
|
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
2013-03-26 10:56:47 +00:00
|
|
|
/// implied 2 zero bits for instrs like 'std'.
|
2013-05-17 12:37:21 +00:00
|
|
|
fixup_ppc_half16ds,
|
2012-12-04 16:18:08 +00:00
|
|
|
|
|
|
|
/// fixup_ppc_tlsreg - Insert thread-pointer register number.
|
|
|
|
fixup_ppc_tlsreg,
|
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
2012-12-11 20:30:11 +00:00
|
|
|
|
2012-12-12 19:29:35 +00:00
|
|
|
/// fixup_ppc_nofixup - Not a true fixup, but ties a symbol to a call
|
|
|
|
/// to __tls_get_addr for the TLS general and local dynamic models.
|
|
|
|
fixup_ppc_nofixup,
|
2010-11-15 06:33:39 +00:00
|
|
|
|
2010-11-15 05:57:53 +00:00
|
|
|
// Marker
|
|
|
|
LastTargetFixupKind,
|
|
|
|
NumTargetFixupKinds = LastTargetFixupKind - FirstTargetFixupKind
|
|
|
|
};
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|