Remove extra argument used once on TargetMachine::getNameWithPrefix and inline the result into the singular caller.

llvm-svn: 281981

Move the Mangler from the AsmPrinter down to TLOF and clean up the
TLOF API accordingly.

llvm-svn: 281708

Use the correct ctor/dtor section for dynamic-no-pic.

llvm-svn: 279967

Move code only used by codegen out of MC. NFC.

MC itself never needs to know about these sections.

llvm-svn: 279965

Add support for allowing us to create uniquely identified "COMDAT" or "ELF
Group" sections while lowering. In particular, for ELF sections this is
useful for creating function-specific groups that ge

Add support for allowing us to create uniquely identified "COMDAT" or "ELF
Group" sections while lowering. In particular, for ELF sections this is
useful for creating function-specific groups that get merged into the
same named section.

Also use const Twine& instead of StringRef for the getELF functions
while we're here.

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

llvm-svn: 274336

show more ...

[ARM] Fix Thumb text sections' flags under COFF/Windows

The main issue here is that the "thumb" flag wasn't set for some of these
sections, making MSVC's link.exe fails to correctly relocate code
ag

[ARM] Fix Thumb text sections' flags under COFF/Windows

The main issue here is that the "thumb" flag wasn't set for some of these
sections, making MSVC's link.exe fails to correctly relocate code
against the symbols inside these sections. link.exe could fail for
instance with the "fixup is not aligned for target 'XX'" error. If
linking doesn't fail, the relocation process goes wrong in the end and
invalid code is generated by the linker.

This patch adds Thumb/ARM information so that the right flags are set
on COFF/Windows.

Patch by Adrien Guinet.

llvm-svn: 273880

show more ...

IR: Introduce local_unnamed_addr attribute.

If a local_unnamed_addr attribute is attached to a global, the address
is known to be insignificant within the module. It is distinct from the
existing un

IR: Introduce local_unnamed_addr attribute.

If a local_unnamed_addr attribute is attached to a global, the address
is known to be insignificant within the module. It is distinct from the
existing unnamed_addr attribute in that it only describes a local property
of the module rather than a global property of the symbol.

This attribute is intended to be used by the code generator and LTO to allow
the linker to decide whether the global needs to be in the symbol table. It is
possible to exclude a global from the symbol table if three things are true:
- This attribute is present on every instance of the global (which means that
the normal rule that the global must have a unique address can be broken without
being observable by the program by performing comparisons against the global's
address)
- The global has linkonce_odr linkage (which means that each linkage unit must have
its own copy of the global if it requires one, and the copy in each linkage unit
must be the same)
- It is a constant or a function (which means that the program cannot observe that
the unique-address rule has been broken by writing to the global)

Although this attribute could in principle be computed from the module
contents, LTO clients (i.e. linkers) will normally need to be able to compute
this property as part of symbol resolution, and it would be inefficient to
materialize every module just to compute it.

See:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html
for earlier discussion.

Part of the fix for PR27553.

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

llvm-svn: 272709

show more ...

Simplify handling of hidden stub.

Since r207518 they are printed exactly like non-hidden stubs on x86 and
since r207517 on ARM.

This means we can use a single set for all stubs in those platforms.

Simplify handling of hidden stub.

Since r207518 they are printed exactly like non-hidden stubs on x86 and
since r207517 on ARM.

This means we can use a single set for all stubs in those platforms.

llvm-svn: 269776

show more ...

Remove .hot and .unlikely prefixes from function section names.

This code currently relies on static methods in ProfileSummary to determine whether a function is hot or unlikley. I am refactoring th

Remove .hot and .unlikely prefixes from function section names.

This code currently relies on static methods in ProfileSummary to determine whether a function is hot or unlikley. I am refactoring the ProfileSummary code and these methods will be removed. As discussed offline, the right way to re-introduce this is to add a pass to annotate functions with unlikely/hot hints and use the hints to determine the prefix here.

llvm-svn: 269726

show more ...

[MC] Create unique .pdata sections for every .text section

Summary:
This adds a unique ID to the COFF section uniquing map, similar to the
one we have for ELF. The unique id is not currently expose

[MC] Create unique .pdata sections for every .text section

Summary:
This adds a unique ID to the COFF section uniquing map, similar to the
one we have for ELF. The unique id is not currently exposed via the
assembler because we don't have a use case for it yet. Users generally
create .pdata with the .seh_* family of directives, and the assembler
internally needs to produce .pdata and .xdata sections corresponding to
the code section.

The association between .text sections and the assembler-created .xdata
and .pdata sections is maintained as an ID field of MCSectionCOFF. The
CFI-related sections are created with the given unique ID, so if more
code is added to the same text section, we can find and reuse the CFI
sections that were already created.

Reviewers: majnemer, rafael

Subscribers: llvm-commits

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

llvm-svn: 268331

show more ...

CodeGen: convert to range based loops

Convert to using some range based loops, avoid unnecessary variables for
unchecked casts. NFC.

llvm-svn: 268165

CodeGen: Use PLT relocations for relative references to unnamed_addr functions.

The relative vtable ABI (PR26723) needs PLT relocations to refer to virtual
functions defined in other DSOs. The unnam

CodeGen: Use PLT relocations for relative references to unnamed_addr functions.

The relative vtable ABI (PR26723) needs PLT relocations to refer to virtual
functions defined in other DSOs. The unnamed_addr attribute means that the
function's address is not significant, so we're allowed to substitute it
with the address of a PLT entry.

Also includes a bonus feature: addends for COFF image-relative references.

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

llvm-svn: 267211

show more ...

Add prefix based function layout when profile is available.

Summary: If a function is hot, put it in text.hot section.

Reviewers: davidxl

Subscribers: llvm-commits

Differential Revision: http://r

Add prefix based function layout when profile is available.

Summary: If a function is hot, put it in text.hot section.

Reviewers: davidxl

Subscribers: llvm-commits

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

llvm-svn: 261607

show more ...

Revert "Add prefix based function layout when profile is available."

This reverts commit r261582, since this bot has been broken for four
hours:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake

Revert "Add prefix based function layout when profile is available."

This reverts commit r261582, since this bot has been broken for four
hours:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/19399/

llvm-svn: 261604

show more ...

[X86] Create mergeable constant pool entries for AVX

We supported creating mergeable constant pool entries for smaller
constants but not for 32-byte AVX constants.

llvm-svn: 261584

Add prefix based function layout when profile is available.

Summary: If a function is hot, put it in text.hot section.

Reviewers: davidxl

Subscribers: eraman, mcrosier, llvm-commits

Differential

Add prefix based function layout when profile is available.

Summary: If a function is hot, put it in text.hot section.

Reviewers: davidxl

Subscribers: eraman, mcrosier, llvm-commits

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

llvm-svn: 261582

show more ...

[X86] Use the correct alignment for COMDAT constant pool entries

COFF doesn't have sections with mergeable contents. Instead, each
constant pool entry ends up in a COMDAT section. The linker, when

[X86] Use the correct alignment for COMDAT constant pool entries

COFF doesn't have sections with mergeable contents. Instead, each
constant pool entry ends up in a COMDAT section. The linker, when
choosing between COMDAT sections, doesn't choose the max alignment of
the two sections. You just get whatever alignment was on the section.

If one constant needed a higher alignment in one object file from
another one, then we will get into trouble if the linker chooses the
lower alignment one.

Instead, lets promote the alignment of the constant pool entry to make
sure we don't use an under aligned constant with an instruction which
assumed otherwise.

This fixes PR26680.

llvm-svn: 261462

show more ...

Stop creating covmap as note section on ELF

covmap needs to created as non allocatable, but not with
SHT_NOTE. The latter was needed to workaround a problem
of BFD linker with gc, which is no longer

Stop creating covmap as note section on ELF

covmap needs to created as non allocatable, but not with
SHT_NOTE. The latter was needed to workaround a problem
of BFD linker with gc, which is no longer needed. (A more
proper longer term fix requires changing FE driver to force
referencing the section using linker script).

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

llvm-svn: 261228

show more ...

[Objective-C] Support a new special module flag.

"Objective-C Class Properties" will be put into the objc_imageinfo struct.

rdar://23891898

llvm-svn: 259270

[PGO] [Coverage] put covmap into note section with no 'alloc flag' (Linux)

Coverage mapping data is not referenced by runtime, and they won't be dumped
into profile data. There is no need to allocat

[PGO] [Coverage] put covmap into note section with no 'alloc flag' (Linux)

Coverage mapping data is not referenced by runtime, and they won't be dumped
into profile data. There is no need to allocate memory for covmap sections.
A good side effect of this change is that the coverage map data won't be mistakenly
garbage collected by the linker (for Gold linker only, BFD linker has an issue where the a bug is filed).
Tested with clang build with instrumentation and -fcoverage-mapping and linker GC. The size of
covmap section is ~17.6M so the text segment size will be reduced by this amount with this change.

llvm-svn: 257781

show more ...

Stop producing .data.rel sections.

If a section is rw, it is irrelevant if the dynamic linker will write to
it or not.

It looks like llvm implemented this because gcc was doing it. It looks
like gc

Stop producing .data.rel sections.

If a section is rw, it is irrelevant if the dynamic linker will write to
it or not.

It looks like llvm implemented this because gcc was doing it. It looks
like gcc implemented this in the hope that it would put all the
relocated items close together and speed up the dynamic linker.

There are two problem with this:
* It doesn't work. Both bfd and gold will map .data.rel to .data and
concatenate the input sections in the order they are seen.
* If we want a feature like that, it can be implemented directly in the
linker since it knowns where the dynamic relocations are.

llvm-svn: 253436

show more ...

Drop prelink support.

The way prelink used to work was

* The compiler decides if a given section only has relocations that
are know to point to the same DSO. If so, it names it
.data.rel.ro.local<s

Drop prelink support.

The way prelink used to work was

* The compiler decides if a given section only has relocations that
are know to point to the same DSO. If so, it names it
.data.rel.ro.local<something>.
* The static linker puts all of these together.
* The prelinker program assigns addresses to each library and resolves
the local relocations.

There are many problems with this:
* It is incompatible with address space randomization.
* The information passed by the compiler is redundant. The linker
knows if a given relocation is in the same DSO or not. If could sort
by that if so desired.
* There are newer ways of speeding up DSO (gnu hash for example).
* Even if we want to implement this again in the compiler, the previous
implementation is pretty broken. It talks about relocations that are
"resolved by the static linker". If they are resolved, there are none
left for the prelinker. What one needs to track is if an expression
will require only dynamic relocations that point to the same DSO.

At this point it looks like the prelinker is an historical curiosity.
For example, fedora has retired it because it failed to build for two
releases
(http://pkgs.fedoraproject.org/cgit/prelink.git/commit/?id=eb43100a8331d91c801ee3dcdb0a0bb9babfdc1f)

This patch removes support for it. That is, it stops printing the
".local" sections.

llvm-svn: 253280

show more ...

CodeGen, Target: Move Mach-O-specific symbol name logic to Mach-O lowering.

A profile of an LTO link of Chrome revealed that we were spending some
~30-50% of execution time in the function Constant:

CodeGen, Target: Move Mach-O-specific symbol name logic to Mach-O lowering.

A profile of an LTO link of Chrome revealed that we were spending some
~30-50% of execution time in the function Constant::getRelocationInfo(),
which is called from TargetLoweringObjectFile::getKindForGlobal() and in turn
from TargetMachine::getNameWithPrefix().

It turns out that we only need the result of getKindForGlobal() when
targeting Mach-O, so this change moves the relevant part of the logic to
TargetLoweringObjectFileMachO.

NFCI.

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

llvm-svn: 252014

show more ...

Sink COFF.h MC include into .cpp files

This prevents MC clients from getting COFF.h, which conflicts with
winnt.h macros. Also a minor IWYU cleanup. Now the only public headers
including COFF.h are

Sink COFF.h MC include into .cpp files

This prevents MC clients from getting COFF.h, which conflicts with
winnt.h macros. Also a minor IWYU cleanup. Now the only public headers
including COFF.h are in Object, and they actually need it.

llvm-svn: 246784

show more ...

Fix some comment typos.

llvm-svn: 244402