[PowerPC] Remove unused includes (NFC) (#116163)

Identified with misc-include-cleaner.

[MC,AArch64] Suppress local symbol to STT_SECTION conversion for GOT relocations

Assemblers change certain relocations referencing a local symbol to
reference the section symbol instead. This conver

[MC,AArch64] Suppress local symbol to STT_SECTION conversion for GOT relocations

Assemblers change certain relocations referencing a local symbol to
reference the section symbol instead. This conversion is disabled for
many conditions (`shouldRelocateWithSymbol`), e.g. TLS symbol, for most
targets (including AArch32, x86, PowerPC, and RISC-V) GOT-generating
relocations.

However, AArch64 encodes the GOT-generating intent in MCValue::RefKind
instead of MCSymbolRef::Kind (see commit
0999cbd0b9ed8aa893cce10d681dec6d54b200ad (2014)), therefore not affected
by the code `case MCSymbolRefExpr::VK_GOT:`. As GNU ld and ld.lld
create GOT entries based on the symbol, ignoring addend, the two ldr
instructions will share the same GOT entry, which is not expected:
```
ldr x1, [x1, :got_lo12:x] // converted to .data+0
ldr x1, [x1, :got_lo12:y] // converted to .data+4

.data
// .globl x, y would suppress STT_SECTION conversion
x:
.zero 4
y:
.long 42
```

This patch changes AArch64 to suppress local symbol to STT_SECTION
conversion for GOT relocations, matching most other targets. x and y
will use different GOT entries, which IMO is the most sensable behavior.

With this change, the ABI decision on https://github.com/ARM-software/abi-aa/issues/217
will only affect relocations explicitly referencing STT_SECTION symbols, e.g.
```
ldr x1, [x1, :got_lo12:(.data+0)]
ldr x1, [x1, :got_lo12:(.data+4)]
// I consider this unreasonable uses
```

IMO all reasonable use cases are unaffected.

Link: https://github.com/llvm/llvm-project/issues/63418
GNU assembler PR: https://sourceware.org/bugzilla/show_bug.cgi?id=30788

Reviewed By: peter.smith

Differential Revision: https://reviews.llvm.org/D158577

show more ...

[PPC32] Emit relocation type R_PPC_DTPREL32 for tls variables

This patch emits the relocation type R_PPC_DTPREL32 for tls variables,
which was previously emitting R_PPC_ADDR32 in power-pc 32bit.

Di

[PPC32] Emit relocation type R_PPC_DTPREL32 for tls variables

This patch emits the relocation type R_PPC_DTPREL32 for tls variables,
which was previously emitting R_PPC_ADDR32 in power-pc 32bit.

Differential Revision: https://reviews.llvm.org/D156953

show more ...

[PowerPC] Allow absolute expressions in relocations

The Linux kernel build uses absolute expressions suffixed with @lo/@ha
relocations. This currently doesn't work for DS/DQ form instructions and
th

[PowerPC] Allow absolute expressions in relocations

The Linux kernel build uses absolute expressions suffixed with @lo/@ha
relocations. This currently doesn't work for DS/DQ form instructions and
there is no reason for it not to. It also works with GAS.
This patch allows this as long as the value is a multiple of 4/16
for DS/DQ form.

Differential revision: https://reviews.llvm.org/D115419

show more ...

[PowerPC][PCRelative] Thread Local Storage Support for Local Dynamic

This patch is the initial support for the Local Dynamic Thread Local Storage
model to produce code sequence and relocation correc

[PowerPC][PCRelative] Thread Local Storage Support for Local Dynamic

This patch is the initial support for the Local Dynamic Thread Local Storage
model to produce code sequence and relocation correct to the ABI for the model
when using PC relative memory operations.

Differential Revision: https://reviews.llvm.org/D87721

show more ...

[PowerPC] Implement Thread Local Storage Support for Local Exec

This patch is the initial support for the Local Exec Thread Local
Storage model to produce code sequence and relocations correct
to th

[PowerPC] Implement Thread Local Storage Support for Local Exec

This patch is the initial support for the Local Exec Thread Local
Storage model to produce code sequence and relocations correct
to the ABI for the model when using PC relative memory operations.

Patch by: Kamau Bridgeman

Differential Revision: https://reviews.llvm.org/D83404

show more ...

[PowerPC][PCRelative] Thread Local Storage Support for Initial Exec

This patch is the initial support for the Intial Exec Thread Local
Local Storage model to produce code sequence and relocations co

[PowerPC][PCRelative] Thread Local Storage Support for Initial Exec

This patch is the initial support for the Intial Exec Thread Local
Local Storage model to produce code sequence and relocations correct
to the ABI for the model when using PC relative memory operations.

Reviewed By: stefanp

Differential Revision: https://reviews.llvm.org/D81947

show more ...

[PowerPC][PCRelative] Thread Local Storage Support for General Dynamic

This patch is the initial support for the General Dynamic Thread Local
Local Storage model to produce code sequence and relocat

[PowerPC][PCRelative] Thread Local Storage Support for General Dynamic

This patch is the initial support for the General Dynamic Thread Local
Local Storage model to produce code sequence and relocations correct
to the ABI for the model when using PC relative memory operations.

Patch by: NeHuang

Reviewed By: stefanp

Differential Revision: https://reviews.llvm.org/D82315

show more ...

[PowerPC] Split s34imm into two types

Currently the instruction paddi always takes s34imm as the type for the
34 bit immediate. However, the PC Relative form of the instruction should
not produce th

[PowerPC] Split s34imm into two types

Currently the instruction paddi always takes s34imm as the type for the
34 bit immediate. However, the PC Relative form of the instruction should
not produce the same fixup as the non PC Relative form.
This patch splits the s34imm type into s34imm and s34imm_pcrel so that two
different fixups can be emitted.

Reviewed By: nemanjai, #powerpc, kamaub

Differential Revision: https://reviews.llvm.org/D83255

show more ...

Temporarily Revert "[PowerPC] Split s34imm into two types"
as it was failing in Release+Asserts mode with an assert.

This reverts commit bd2068031121adf5a0e28d9306a1741d6f0bbd87.

[PowerPC] Split s34imm into two types

Currently the instruction paddi always takes s34imm as the type for the
34 bit immediate. However, the PC Relative form of the instruction should
not produce th

[PowerPC] Split s34imm into two types

Currently the instruction paddi always takes s34imm as the type for the
34 bit immediate. However, the PC Relative form of the instruction should
not produce the same fixup as the non PC Relative form.
This patch splits the s34imm type into s34imm and s34imm_pcrel so that two
different fixups can be emitted.

Reviewed By: kamaub, nemanjai

Differential Revision: https://reviews.llvm.org/D83255

show more ...

[PowerPC][Future] More support for PCRel addressing for global values

Add initial support for PC Relative addressing for global values that
require GOT indirect addressing. This patch adds PCRelativ

[PowerPC][Future] More support for PCRel addressing for global values

Add initial support for PC Relative addressing for global values that
require GOT indirect addressing. This patch adds PCRelative support for
global addresses that may not be known at link time and may require
access through the GOT.

Differential Revision: https://reviews.llvm.org/D76064

show more ...

[PowerPC][Future] Initial support for PCRel addressing for constant pool loads

Add initial support for PC Relative addressing for constant pool loads.
This includes adding a new relocation for @pcre

[PowerPC][Future] Initial support for PCRel addressing for constant pool loads

Add initial support for PC Relative addressing for constant pool loads.
This includes adding a new relocation for @pcrel and adding a new PowerPC flag
to identify PC relative addressing.

Differential Revision: https://reviews.llvm.org/D74486

show more ...

[PowerPC][Future] Add Support For Functions That Do Not Use A TOC.

On PowerPC most functions require a valid TOC pointer.

This is the case because either the function itself needs to use this
point

[PowerPC][Future] Add Support For Functions That Do Not Use A TOC.

On PowerPC most functions require a valid TOC pointer.

This is the case because either the function itself needs to use this
pointer to access the TOC or because other functions that are called
from that function expect a valid TOC pointer in the register R2.
The main exception to this is leaf functions that do not access the TOC
since they are guaranteed not to need a valid TOC pointer.

This patch introduces a feature that will allow more functions to not
require a valid TOC pointer in R2.

Differential Revision: https://reviews.llvm.org/D73664

show more ...

[MC][PowerPC] Make .reloc support arbitrary relocation types

Generalizes ad7199f3e60a49db023099dcb879fcc9cdf94a2e (R_PPC_NONE/R_PPC64_NONE).

[MC] Minor cleanup to MCFixup::Kind handling. NFC.

Prefer `MCFixupKind` where possible and add getTargetKind() to
convert to `unsigned` when needed rather than scattering cast
operators around the p

[MC] Minor cleanup to MCFixup::Kind handling. NFC.

Prefer `MCFixupKind` where possible and add getTargetKind() to
convert to `unsigned` when needed rather than scattering cast
operators around the place.

Differential Revision: https://reviews.llvm.org/D59890

llvm-svn: 369720

show more ...

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013

show more ...

[PowerPC] Support .reloc *, R_PPC{,64}_NONE, *

This can be used to create references among sections. When --gc-sections
is used, the referenced section will be retained if the origin section
is reta

[PowerPC] Support .reloc *, R_PPC{,64}_NONE, *

This can be used to create references among sections. When --gc-sections
is used, the referenced section will be retained if the origin section
is retained.

llvm-svn: 360990

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[PowerPC] Add support for high and higha symbol modifiers on tls modifers.

Enables using the high and high-adjusted symbol modifiers on thread local
storage modifers in powerpc assembly. Needed to b

[PowerPC] Add support for high and higha symbol modifiers on tls modifers.

Enables using the high and high-adjusted symbol modifiers on thread local
storage modifers in powerpc assembly. Needed to be able to support 64 bit
thread-pointer and dynamic-thread-pointer access sequences.

Differential Revision: https://reviews.llvm.org/D47754

llvm-svn: 334856

show more ...

[PPC64] Support "symbol@high" and "symbol@higha" symbol modifers.

Add support for the "@high" and "@higha" symbol modifiers in powerpc64 assembly.
The modifiers represent accessing the segment consi

[PPC64] Support "symbol@high" and "symbol@higha" symbol modifers.

Add support for the "@high" and "@higha" symbol modifiers in powerpc64 assembly.
The modifiers represent accessing the segment consiting of bits 16-31 of a
64-bit address/offset.

Differential Revision: https://reviews.llvm.org/D47729

llvm-svn: 334855

show more ...

MC: Separate creating a generic object writer from creating a target object writer. NFCI.

With this we gain a little flexibility in how the generic object
writer is created.

Part of PR37466.

Diffe

MC: Separate creating a generic object writer from creating a target object writer. NFCI.

With this we gain a little flexibility in how the generic object
writer is created.

Part of PR37466.

Differential Revision: https://reviews.llvm.org/D47045

llvm-svn: 332868

show more ...

[MC] Thread unique_ptr<MCObjectWriter> through the create.*ObjectWriter
functions.

This makes the ownership of the resulting MCObjectWriter clear, and allows us
to remove one instance of MCObjectStr

[MC] Thread unique_ptr<MCObjectWriter> through the create.*ObjectWriter
functions.

This makes the ownership of the resulting MCObjectWriter clear, and allows us
to remove one instance of MCObjectStreamer's bizarre "holding ownership via
someone else's reference" trick.

llvm-svn: 315327

show more ...

[MC] Plumb unique_ptr<MCELFObjectTargetWriter> through createELFObjectWriter to
ELFObjectWriter's constructor.

Fixes the same ownership issue for ELF that r315245 did for MachO:
ELFObjectWriter take

[MC] Plumb unique_ptr<MCELFObjectTargetWriter> through createELFObjectWriter to
ELFObjectWriter's constructor.

Fixes the same ownership issue for ELF that r315245 did for MachO:
ELFObjectWriter takes ownership of its MCELFObjectTargetWriter, so we want to
pass this through to the constructor via a unique_ptr, rather than a raw ptr.

llvm-svn: 315254

show more ...

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.

I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.

This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.

Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).

llvm-svn: 304787

show more ...