Revert "Revert r240762 "[X86] Cleanup X86WindowsTargetObjectFile::getSectionForConstant""

This reverts commit r240793 while fixing how we handle array constant
pool entries.

This fixes PR23966.

ll

Revert "Revert r240762 "[X86] Cleanup X86WindowsTargetObjectFile::getSectionForConstant""

This reverts commit r240793 while fixing how we handle array constant
pool entries.

This fixes PR23966.

llvm-svn: 240811

show more ...

Revert r240762 "[X86] Cleanup X86WindowsTargetObjectFile::getSectionForConstant"

It seems to have caused PR23966: "UNREACHABLE executed at ..\lib\Target\X86\X86TargetObjectFile.cpp:148"

llvm-svn: 2

Revert r240762 "[X86] Cleanup X86WindowsTargetObjectFile::getSectionForConstant"

It seems to have caused PR23966: "UNREACHABLE executed at ..\lib\Target\X86\X86TargetObjectFile.cpp:148"

llvm-svn: 240793

show more ...

[X86] Cleanup X86WindowsTargetObjectFile::getSectionForConstant

No functionality changed, just keeping things clean.

llvm-svn: 240762

MC: Clean up MCExpr naming. NFC.

llvm-svn: 238634

Move alignment from MCSectionData to MCSection.

This starts merging MCSection and MCSectionData.

There are a few issues with the current split between MCSection and
MCSectionData.

* It optimizes t

Move alignment from MCSectionData to MCSection.

This starts merging MCSection and MCSectionData.

There are a few issues with the current split between MCSection and
MCSectionData.

* It optimizes the the not as important case. We want the production
of .o files to be really fast, but the split puts the information used
for .o emission in a separate data structure.

* The ELF/COFF/MachO hierarchy is not represented in MCSectionData,
leading to some ad-hoc ways to represent the various flags.

* It makes it harder to remember where each item is.

The attached patch starts merging the two by moving the alignment from
MCSectionData to MCSection.

Most of the patch is actually just dropping 'const', since
MCSectionData is mutable, but MCSection was not.

llvm-svn: 237936

show more ...

Make NaCl's use of .init_array for static constructors match Linux

Summary:
The generic ELF TargetObjectFile defaults to .ctors, but Linux's
defaults to .init_array by calling InitializeELF with the

Make NaCl's use of .init_array for static constructors match Linux

Summary:
The generic ELF TargetObjectFile defaults to .ctors, but Linux's
defaults to .init_array by calling InitializeELF with the value of
UseInitArray from TargetMachine. Make NaCl's behavior match.

Reviewers: jvoung
Differential Revision: http://reviews.llvm.org/D8240

llvm-svn: 231934

show more ...

[AsmPrinter][TLOF] 32-bit MachO support for replacing GOT equivalents

Add MachO 32-bit (i.e. arm and x86) support for replacing global GOT equivalent
symbol accesses. Unlike 64-bit targets, there's

[AsmPrinter][TLOF] 32-bit MachO support for replacing GOT equivalents

Add MachO 32-bit (i.e. arm and x86) support for replacing global GOT equivalent
symbol accesses. Unlike 64-bit targets, there's no GOTPCREL relocation, and
access through a non_lazy_symbol_pointers section is used instead.

-- before

_extgotequiv:
.long _extfoo

_delta:
.long _extgotequiv-_delta

-- after

_delta:
.long L_extfoo$non_lazy_ptr-_delta

.section __IMPORT,__pointers,non_lazy_symbol_pointers
L_extfoo$non_lazy_ptr:
.indirect_symbol _extfoo
.long 0

llvm-svn: 231475

show more ...

[AsmPrinter][TLOF] ARM64 MachO support for replacing GOT equivalents

Follow up r230264 and add ARM64 support for replacing global GOT
equivalent symbol accesses by references to the GOT entry for th

[AsmPrinter][TLOF] ARM64 MachO support for replacing GOT equivalents

Follow up r230264 and add ARM64 support for replacing global GOT
equivalent symbol accesses by references to the GOT entry for the final
symbol instead, example:

-- before

.globl _foo
_foo:
.long 42

.globl _gotequivalent
_gotequivalent:
.quad _foo

.globl _delta
_delta:
.long _gotequivalent-_delta

-- after

.globl _foo
_foo:
.long 42

.globl _delta
Ltmp3:
.long _foo@GOT-Ltmp3

llvm-svn: 231474

show more ...

X86: Form IMGREL relocations for LLVM Functions

We supported forming IMGREL relocations from ConstantExprs involving
__ImageBase if the minuend was a GlobalVariable. Extend this
functionality to al

X86: Form IMGREL relocations for LLVM Functions

We supported forming IMGREL relocations from ConstantExprs involving
__ImageBase if the minuend was a GlobalVariable. Extend this
functionality to all GlobalObjects.

llvm-svn: 231456

show more ...

[X86][ELF] Correct relocation for DWARF TLS references
Previously we had only Linux using DTPOFF for these; all X86 ELF
targets should. Fixes a side issue mentioned in PR21077.

Differential Revision

[X86][ELF] Correct relocation for DWARF TLS references
Previously we had only Linux using DTPOFF for these; all X86 ELF
targets should. Fixes a side issue mentioned in PR21077.

Differential Revision: http://reviews.llvm.org/D8011

llvm-svn: 231130

show more ...

Revert r230979, should apply to all X86 ELF.

llvm-svn: 230985

[PS4] Correct relocation for DWARF TLS references.

llvm-svn: 230979

[AsmPrinter] Access pointers to globals via pcrel GOT entries

Front-ends could use global unnamed_addr to hold pointers to other
symbols, like @gotequivalent below:

@foo = global i32 42
@gotequival

[AsmPrinter] Access pointers to globals via pcrel GOT entries

Front-ends could use global unnamed_addr to hold pointers to other
symbols, like @gotequivalent below:

@foo = global i32 42
@gotequivalent = private unnamed_addr constant i32* @foo

@delta = global i32 trunc (i64 sub (i64 ptrtoint (i32** @gotequivalent to i64),
i64 ptrtoint (i32* @delta to i64))
to i32)

The global @delta holds a data "PC"-relative offset to @gotequivalent,
an unnamed pointer to @foo. The darwin/x86-64 assembly output for this follows:

.globl _foo
_foo:
.long 42

.globl _gotequivalent
_gotequivalent:
.quad _foo

.globl _delta
_delta:
.long _gotequivalent-_delta

Since unnamed_addr indicates that the address is not significant, only
the content, we can optimize the case above by replacing pc-relative
accesses to "GOT equivalent" globals, by a PC relative access to the GOT
entry of the final symbol instead. Therefore, "delta" can contain a pc
relative relocation to foo's GOT entry and we avoid the emission of
"gotequivalent", yielding the assembly code below:

.globl _foo
_foo:
.long 42

.globl _delta
_delta:
.long _foo@GOTPCREL+4

There are a couple of advantages of doing this: (1) Front-ends that need
to emit a great deal of data to store pointers to external symbols could
save space by not emitting such "got equivalent" globals and (2) IR
constructs combined with this opt opens a way to represent GOT pcrel
relocations by using the LLVM IR, which is something we previously had
no way to express.

Differential Revision: http://reviews.llvm.org/D6922

rdar://problem/18534217

llvm-svn: 230264

show more ...

X86: Simplify X86WindowsTargetObjectFile::getSectionForConstant

There exists a helper function to abstract away the various differences
between ConstantVector, ConstantDataVector, ConstantAggregateZ

X86: Simplify X86WindowsTargetObjectFile::getSectionForConstant

There exists a helper function to abstract away the various differences
between ConstantVector, ConstantDataVector, ConstantAggregateZero, etc.

Use it to simplify X86WindowsTargetObjectFile::getSectionForConstant.

llvm-svn: 213104

show more ...

CodeGen: Handle ConstantVector and undef in WinCOFF constant pools

The constant pool entry code for WinCOFF assumed that vector constants
would be formed using ConstantDataVector, it did not expect

CodeGen: Handle ConstantVector and undef in WinCOFF constant pools

The constant pool entry code for WinCOFF assumed that vector constants
would be formed using ConstantDataVector, it did not expect to see a
ConstantVector. Furthermore, it did not expect undef as one of the
elements of the vector.

ConstantVectors should be handled like ConstantDataVectors, treat Undef
as zero.

llvm-svn: 213038

show more ...

CodeGen: Stick constant pool entries in COMDAT sections for WinCOFF

COFF lacks a feature that other object file formats support: mergeable
sections.

To work around this, MSVC sticks constant pool e

CodeGen: Stick constant pool entries in COMDAT sections for WinCOFF

COFF lacks a feature that other object file formats support: mergeable
sections.

To work around this, MSVC sticks constant pool entries in special COMDAT
sections so that each constant is in it's own section. This permits
unused constants to be dropped and it also allows duplicate constants in
different translation units to get merged together.

This fixes PR20262.

Differential Revision: http://reviews.llvm.org/D4482

llvm-svn: 213006

show more ...

Restore condition incorrectly changed in r96289 to the older state.

llvm-svn: 207716

[C++] Use 'nullptr'. Target edition.

llvm-svn: 207197

move getNameWithPrefix and getSymbol to TargetMachine.

TargetLoweringBase is implemented in CodeGen, so before this patch we had
a dependency fom Target to CodeGen. This would show up as a link fail

move getNameWithPrefix and getSymbol to TargetMachine.

TargetLoweringBase is implemented in CodeGen, so before this patch we had
a dependency fom Target to CodeGen. This would show up as a link failure of
llvm-stress when building with -DBUILD_SHARED_LIBS=ON.

This fixes pr18900.

llvm-svn: 201711

show more ...

Add back r201608, r201622, r201624 and r201625

r201608 made llvm corretly handle private globals with MachO. r201622 fixed
a bug in it and r201624 and r201625 were changes for using private linkage,

Add back r201608, r201622, r201624 and r201625

r201608 made llvm corretly handle private globals with MachO. r201622 fixed
a bug in it and r201624 and r201625 were changes for using private linkage,
assuming that llvm would do the right thing.

They all got reverted because r201608 introduced a crash in LTO. This patch
includes a fix for that. The issue was that TargetLoweringObjectFile now has
to be initialized before we can mangle names of private globals. This is
trivially true during the normal codegen pipeline (the asm printer does it),
but LTO has to do it manually.

llvm-svn: 201700

show more ...

Revert r201622 and r201608.

This causes the LLVMgold plugin to segfault. More information on the
replies to r201608.

llvm-svn: 201669

Fix PR18743.

The IR
@foo = private constant i32 42

is valid, but before this patch we would produce an invalid MachO from it. It
was invalid because it would use an L label in a section where the l

Fix PR18743.

The IR
@foo = private constant i32 42

is valid, but before this patch we would produce an invalid MachO from it. It
was invalid because it would use an L label in a section where the liker needs
the labels in order to atomize it.

One way of fixing it would be to just reject this IR in the backend, but that
would not be very front end friendly.

What this patch does is use an 'l' prefix in sections that we know the linker
requires symbols for atomizing them. This allows frontends to just use
private and not worry about which sections they go to or how the linker handles
them.

One small issue with this strategy is that now a symbol name depends on the
section, which is not available before codegen. This is not a problem in
practice. The reason is that it only happens with private linkage, which will
be ignored by the non codegen users (llvm-nm and llvm-ar).

llvm-svn: 201608

show more ...

Use a consistent argument order in TargetLoweringObjectFile.

These methods normally call each other and it is really annoying if the
arguments are in different order. The more common rule was that t

Use a consistent argument order in TargetLoweringObjectFile.

These methods normally call each other and it is really annoying if the
arguments are in different order. The more common rule was that the arguments
specific to call are first (GV, Encoding, Suffix) and the auxiliary objects
(Mang, TM) come after. This patch changes the exceptions.

llvm-svn: 201044

show more ...

Pass the Mangler by reference.

It is never null and it is not used in casts, so there is no reason to use a
pointer. This matches how we pass TM.

llvm-svn: 201025

WinCOFF: Transform IR expressions featuring __ImageBase into image relative relocations

MSVC on x64 requires that we create image relative symbol
references to refer to RTTI data. Seeing as how ther

WinCOFF: Transform IR expressions featuring __ImageBase into image relative relocations

MSVC on x64 requires that we create image relative symbol
references to refer to RTTI data. Seeing as how there is no way to
explicitly make reference to a given relocation type in LLVM IR, pattern
match expressions of the form &foo - &__ImageBase.

Differential Revision: http://llvm-reviews.chandlerc.com/D2523

llvm-svn: 199312

show more ...