BitcodeReader: Consistently use IsDistinct, NFC

Consistently use the IsDistinct variable and start relying on it in
GET_OR_DISTINCT. This change has NFC, but prepares for using IsDistinct
to optimi

BitcodeReader: Consistently use IsDistinct, NFC

Consistently use the IsDistinct variable and start relying on it in
GET_OR_DISTINCT. This change has NFC, but prepares for using IsDistinct
to optimize the behaviour of the getMD() and getMDOrNull() helpers.

llvm-svn: 267268

show more ...

BitcodeReader: Use getMD/getMDOrNull helpers consistently, almost NFC

The only functionality change was removing an error check from the
BitcodeReader (and an assertion from DILocation::getImpl) tha

BitcodeReader: Use getMD/getMDOrNull helpers consistently, almost NFC

The only functionality change was removing an error check from the
BitcodeReader (and an assertion from DILocation::getImpl) that is
already caught by Verifier::visitDILocation. The Verifier is a better
place for this anyway, and being inconsistent with other subclasses of
MDNode isn't serving anyone.

llvm-svn: 267267

show more ...

[ThinLTO] Remove unused/incomplete lazy summary reading support (NFC)

This removes the interfaces added (and not yet complete) to support
lazy reading of summaries. This support is not expected to b

[ThinLTO] Remove unused/incomplete lazy summary reading support (NFC)

This removes the interfaces added (and not yet complete) to support
lazy reading of summaries. This support is not expected to be needed
since we are moving to a model where the full index is only being
traversed in the thin link step, instead of the back ends.

(The second part of this that I plan to do next is remove the
GlobalValueInfo from the ModuleSummaryIndex - it was mostly needed to
support lazy parsing of summaries. The index can instead reference the
summary structures directly.)

llvm-svn: 267097

show more ...

IR: Use SmallVector instead of std::vector of TrackingMDRef

Don't use std::vector<TrackingMDRef>, since (at least in some versions
of libc++) std::vector apparently copies values on grow operations

IR: Use SmallVector instead of std::vector of TrackingMDRef

Don't use std::vector<TrackingMDRef>, since (at least in some versions
of libc++) std::vector apparently copies values on grow operations
instead of moving them. Found this when I was temporarily deleting the
copy constructor for TrackingMDRef to investigate a performance
bottleneck.

llvm-svn: 266909

show more ...

IR: Enable debug info type ODR uniquing for forward decls

Add a new method, DICompositeType::buildODRType, that will create or
mutate the DICompositeType for a given ODR identifier, and use it in
LL

IR: Enable debug info type ODR uniquing for forward decls

Add a new method, DICompositeType::buildODRType, that will create or
mutate the DICompositeType for a given ODR identifier, and use it in
LLParser and BitcodeReader instead of DICompositeType::getODRType.

The logic is as follows:

- If there's no node, create one with the given arguments.
- Else, if the current node is a forward declaration and the new
arguments would create a definition, mutate the node to match the
new arguments.
- Else, return the old node.

This adds a missing feature supported by the current DITypeIdentifierMap
(which I'm slowly making redudant). The only remaining difference is
that the DITypeIdentifierMap has a "the-last-one-wins" rule, whereas
DICompositeType::buildODRType has a "the-first-one-wins" rule.

For now I'm leaving behind DICompositeType::getODRType since it has
obvious, low-level semantics that are convenient for unit testing.

llvm-svn: 266786

show more ...

IR: getOrInsertODRUniquedType => DICompositeType::getODRType, NFC

Lift the API for debug info ODR type uniquing up a layer. Instead of
clients managing the map directly on the LLVMContext, add a st

IR: getOrInsertODRUniquedType => DICompositeType::getODRType, NFC

Lift the API for debug info ODR type uniquing up a layer. Instead of
clients managing the map directly on the LLVMContext, add a static
method to DICompositeType called getODRType and handle the map in the
background. Also adds DICompositeType::getODRTypeIfExists, so far just
for convenience in the unit tests.

This simplifies the logic in LLParser and BitcodeReader. Because of
argument spam there are actually a few more lines of code now; I'll see
if I come up with a reasonable way to clean that up.

llvm-svn: 266742

show more ...

IR: Require DICompositeType for ODR uniquing type map

Tighten up the API for debug info ODR type uniquing in LLVMContext. The
only reason to allow other DIType subclasses is to make the unit tests

IR: Require DICompositeType for ODR uniquing type map

Tighten up the API for debug info ODR type uniquing in LLVMContext. The
only reason to allow other DIType subclasses is to make the unit tests
prettier :/.

llvm-svn: 266737

show more ...

IR: Rename API for enabling ODR uniquing of DITypes, NFC

As per David's review, rename everything in the new API for ODR type
uniquing of debug info.

ensureDITypeMap => enableDebugTypeODRUniqu

IR: Rename API for enabling ODR uniquing of DITypes, NFC

As per David's review, rename everything in the new API for ODR type
uniquing of debug info.

ensureDITypeMap => enableDebugTypeODRUniquing
destroyDITypeMap => disableDebugTypeODRUniquing
hasDITypeMap => isODRUniquingDebugTypes

llvm-svn: 266713

show more ...

IR: Use an explicit map for debug info type uniquing

Rather than relying on the structural equivalence of DICompositeType to
merge type definitions, use an explicit map on the LLVMContext that
LLPar

IR: Use an explicit map for debug info type uniquing

Rather than relying on the structural equivalence of DICompositeType to
merge type definitions, use an explicit map on the LLVMContext that
LLParser and BitcodeReader consult when constructing new nodes.
Each non-forward-declaration DICompositeType with a non-empty
'identifier:' field is stored/loaded from the type map, and the first
definiton will "win".

This map is opt-in: clients that expect ODR types from different modules
to be merged must call LLVMContext::ensureDITypeMap.

- Clients that just happen to load more than one Module in the same
LLVMContext won't magically merge types.

- Clients (like LTO) that want to continue to merge types based on ODR
identifiers should opt-in immediately.

I have updated LTOCodeGenerator.cpp, the two "linking" spots in
gold-plugin.cpp, and llvm-link (unless -disable-debug-info-type-map) to
set this.

With this in place, it will be straightforward to remove the DITypeRef
concept (i.e., referencing types by their 'identifier:' string rather
than pointing at them directly).

llvm-svn: 266549

show more ...

ThinLTO: Make aliases explicit in the summary

To be able to work accurately on the reference graph when taking
decision about internalizing, promoting, renaming, etc. We need
to have the alias infor

ThinLTO: Make aliases explicit in the summary

To be able to work accurately on the reference graph when taking
decision about internalizing, promoting, renaming, etc. We need
to have the alias information explicit.

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266517

show more ...

[PR27284] Reverse the ownership between DICompileUnit and DISubprogram.

Currently each Function points to a DISubprogram and DISubprogram has a
scope field. For member functions the scope is a DICom

[PR27284] Reverse the ownership between DICompileUnit and DISubprogram.

Currently each Function points to a DISubprogram and DISubprogram has a
scope field. For member functions the scope is a DICompositeType. DIScopes
point to the DICompileUnit to facilitate type uniquing.

Distinct DISubprograms (with isDefinition: true) are not part of the type
hierarchy and cannot be uniqued. This change removes the subprograms
list from DICompileUnit and instead adds a pointer to the owning compile
unit to distinct DISubprograms. This would make it easy for ThinLTO to
strip unneeded DISubprograms and their transitively referenced debug info.

Motivation
----------

Materializing DISubprograms is currently the most expensive operation when
doing a ThinLTO build of clang.

We want the DISubprogram to be stored in a separate Bitcode block (or the
same block as the function body) so we can avoid having to expensively
deserialize all DISubprograms together with the global metadata. If a
function has been inlined into another subprogram we need to store a
reference the block containing the inlined subprogram.

Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script
that updates LLVM IR testcases to the new format.

http://reviews.llvm.org/D19034
<rdar://problem/25256815>

llvm-svn: 266446

show more ...

Revert "Make aliases explicit in the summary"

Inadvertently commited...

This reverts commit e618ec93786d99df2ddf280ad2d5e02f5516cecf.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266215

Make aliases explicit in the summary

Summary:
To be able to work accurately on the reference graph when taking decision
about internalizing, promoting, renaming, etc. We need to have the alias
infor

Make aliases explicit in the summary

Summary:
To be able to work accurately on the reference graph when taking decision
about internalizing, promoting, renaming, etc. We need to have the alias
information explicit.

Reviewers: tejohnson

Subscribers: llvm-commits

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266214

show more ...

Add the allocsize attribute to LLVM.

`allocsize` is a function attribute that allows users to request that
LLVM treat arbitrary functions as allocation functions.

This patch makes LLVM accept the `

Add the allocsize attribute to LLVM.

`allocsize` is a function attribute that allows users to request that
LLVM treat arbitrary functions as allocation functions.

This patch makes LLVM accept the `allocsize` attribute, and makes
`@llvm.objectsize` recognize said attribute.

The review for this was split into two patches for ease of reviewing:
D18974 and D14933. As promised on the revisions, I'm landing both
patches as a single commit.

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

llvm-svn: 266032

show more ...

[GCC] Attribute ifunc support in llvm

This patch add support for GCC attribute((ifunc("resolver"))) for
targets that use ELF as object file format. In general ifunc is a
special kind of function ali

[GCC] Attribute ifunc support in llvm

This patch add support for GCC attribute((ifunc("resolver"))) for
targets that use ELF as object file format. In general ifunc is a
special kind of function alias with type @gnu_indirect_function. Patch
for Clang http://reviews.llvm.org/D15524

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

llvm-svn: 265667

show more ...

NFC: make AtomicOrdering an enum class

Summary:
In the context of http://wg21.link/lwg2445 C++ uses the concept of
'stronger' ordering but doesn't define it properly. This should be fixed
in C++17 b

NFC: make AtomicOrdering an enum class

Summary:
In the context of http://wg21.link/lwg2445 C++ uses the concept of
'stronger' ordering but doesn't define it properly. This should be fixed
in C++17 barring a small question that's still open.

The code currently plays fast and loose with the AtomicOrdering
enum. Using an enum class is one step towards tightening things. I later
also want to tighten related enums, such as clang's
AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI'
enum).

This change touches a few lines of code which can be improved later, I'd
like to keep it as NFC for now as it's already quite complex. I have
related changes for clang.

As a follow-up I'll add:
bool operator<(AtomicOrdering, AtomicOrdering) = delete;
bool operator>(AtomicOrdering, AtomicOrdering) = delete;
bool operator<=(AtomicOrdering, AtomicOrdering) = delete;
bool operator>=(AtomicOrdering, AtomicOrdering) = delete;
This is separate so that clang and LLVM changes don't need to be in sync.

Reviewers: jyknight, reames

Subscribers: jyknight, llvm-commits

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

llvm-svn: 265602

show more ...

[IFUNC] Use GlobalIndirectSymbol when aliases and ifuncs have something similar

Second part extracted from http://reviews.llvm.org/D15525

Use GlobalIndirectSymbol in all cases when aliases and ifun

[IFUNC] Use GlobalIndirectSymbol when aliases and ifuncs have something similar

Second part extracted from http://reviews.llvm.org/D15525

Use GlobalIndirectSymbol in all cases when aliases and ifuncs have
something in common.

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

llvm-svn: 265382

show more ...

[ThinLTO] Refactor some common code into getGlobalValueInfo method (NFC)

Refactor common code that queries the ModuleSummaryIndex for a value's
GlobalValueInfo struct into getGlobalValueInfo helper

[ThinLTO] Refactor some common code into getGlobalValueInfo method (NFC)

Refactor common code that queries the ModuleSummaryIndex for a value's
GlobalValueInfo struct into getGlobalValueInfo helper methods, which
will also be used by D18763.

llvm-svn: 265370

show more ...

[ThinLTO] Add option to dump value name to GUID mapping

Summary:
Useful for debugging since we lose this correlation after the permodule
summary/VST is read and until we later materialize source mod

[ThinLTO] Add option to dump value name to GUID mapping

Summary:
Useful for debugging since we lose this correlation after the permodule
summary/VST is read and until we later materialize source modules in the
function importer.

Reviewers: joker.eph

Subscribers: llvm-commits, joker.eph

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

llvm-svn: 265327

show more ...

BitcodeReader: Check for unresolved function metadata

A follow-up commit will start using function metadata blocks more
heavily. This commit adds some error checking to confirm that metadata
is ful

BitcodeReader: Check for unresolved function metadata

A follow-up commit will start using function metadata blocks more
heavily. This commit adds some error checking to confirm that metadata
is fully resolved before (and after) materializing each function.

This is valid even when reading very old bitcode from before the
metadata/value split. The global metadata block always came before the
function blocks. However, in case somehow this causes a regression
(i.e., an old LLVM did produce such bitcode after all) I'm committing
separately.

llvm-svn: 265223

show more ...

Create a typedef GlobalValue::GUID for uint64_t and RAUW (NFC)

Summary: This should make the code more readable, especially all the map declarations.

Reviewers: tejohnson

Subscribers: llvm-commit

Create a typedef GlobalValue::GUID for uint64_t and RAUW (NFC)

Summary: This should make the code more readable, especially all the map declarations.

Reviewers: tejohnson

Subscribers: llvm-commits

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265215

show more ...

Swift Calling Convention: add swifterror attribute.

A ``swifterror`` attribute can be applied to a function parameter or an
AllocaInst.

This commit does not include any target-specific change. The

Swift Calling Convention: add swifterror attribute.

A ``swifterror`` attribute can be applied to a function parameter or an
AllocaInst.

This commit does not include any target-specific change. The target-specific
optimization will come as a follow-up patch.

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

llvm-svn: 265189

show more ...

Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id"

This is intended to be used for ThinLTO incremental build.

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

Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id"

This is intended to be used for ThinLTO incremental build.

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

This is a recommit of r265095 after fixing the Windows issues.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265111

show more ...

Revert "Add support for computing SHA1 in LLVM"

This reverts commit r265096, r265095, and r265094.
Windows build is broken, and the validation does not pass.

From: Mehdi Amini <mehdi.amini@apple.co

Revert "Add support for computing SHA1 in LLVM"

This reverts commit r265096, r265095, and r265094.
Windows build is broken, and the validation does not pass.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265102

show more ...

Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id"

This is intended to be used for ThinLTO incremental build.

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

Add a module Hash in the bitcode and the combined index, implementing a kind of "build-id"

This is intended to be used for ThinLTO incremental build.

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265095

show more ...