Revert "Make aliases explicit in the summary"

Inadvertently commited...

This reverts commit e618ec93786d99df2ddf280ad2d5e02f5516cecf.

From: Mehdi Amini <[email protected]>
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 <[email protected]>
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 ...

[ThinLTO] Move summary computation from BitcodeWriter to new pass

Summary:
This is the first step in also serializing the index out to LLVM
assembly.

The per-module summary written to bitcode is mo

[ThinLTO] Move summary computation from BitcodeWriter to new pass

Summary:
This is the first step in also serializing the index out to LLVM
assembly.

The per-module summary written to bitcode is moved out of the bitcode
writer and to a new analysis pass (ModuleSummaryIndexWrapperPass).
The pass itself uses a new builder class to compute index, and the
builder class is used directly in places where we don't have a pass
manager (e.g. llvm-as).

Because we are computing summaries outside of the bitcode writer, we no
longer can use value ids created by the bitcode writer's
ValueEnumerator. This required changing the reference graph edge type
to use a new ValueInfo class holding a union between a GUID (combined
index) and Value* (permodule index). The Value* are converted to the
appropriate value ID during bitcode writing.

Also, this enables removal of the BitWriter library's dependence on the
Analysis library that was previously required for the summary computation.

Reviewers: joker.eph

Subscribers: joker.eph, llvm-commits

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

llvm-svn: 265941

show more ...

Rename parameter I to Index for WriteCombinedGlobalValueSummary() (NFC)

From: Mehdi Amini <[email protected]>
llvm-svn: 265729

[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 ...

IR: Introduce ConstantAggregate, NFC

Add a common parent class for ConstantArray, ConstantVector, and
ConstantStruct called ConstantAggregate. These are the aggregate
subclasses of Constant that ta

IR: Introduce ConstantAggregate, NFC

Add a common parent class for ConstantArray, ConstantVector, and
ConstantStruct called ConstantAggregate. These are the aggregate
subclasses of Constant that take operands.

This is mainly a cleanup, adding common `isa` target and removing
duplicated code. However, it also simplifies caching which constants
point transitively at `GlobalValue` (a possible future direction).

llvm-svn: 265466

show more ...

Rename FunctionIndex into GlobalValueIndex to reflect the recent changes (NFC)

The index used to contain only Function, but now contains GlobalValue
in general.

From: Mehdi Amini <mehdi.amini@apple

Rename FunctionIndex into GlobalValueIndex to reflect the recent changes (NFC)

The index used to contain only Function, but now contains GlobalValue
in general.

From: Mehdi Amini <[email protected]>
llvm-svn: 265230

show more ...

Bitcode: Try to emit metadata in function blocks

Whenever metadata is only referenced by a single function, emit the
metadata just in that function block. This should improve lazy-loading
by reduci

Bitcode: Try to emit metadata in function blocks

Whenever metadata is only referenced by a single function, emit the
metadata just in that function block. This should improve lazy-loading
by reducing the amount of metadata in the global block.

For now, this should catch all DILocations, and anything else that
happens to be referenced only by a single function.

It's also a first step toward a couple of possible future directions
(which this commit does *not* implement):

1. Some debug info metadata is only referenced from compile units and
individual functions. If we can drop the link from the compile
unit, this optimization will get more powerful.

2. Any uniqued metadata that isn't referenced globally can in theory be
emitted in every function block that references it (trading off
bitcode size and full-parse time vs. lazy-load time).

Note: this assumes the new BitcodeReader error checking from r265223.
The metadata stored in function blocks gets purged after parsing each
function, which means unresolved forward references will get lost.
Since all the global metadata should have already been resolved by the
time we get to the function metadata blocks we just need to check for
that case. (If for some reason we need to handle bitcode that fails the
checks in r265223, the fix is to store about-to-be-dropped unresolved
nodes in MetadataList::shrinkTo until they can be handled succesfully by
a future call to MetadataList::tryToResolveCycles.)

llvm-svn: 265226

show more ...

BitcodeWriter: Further unify function metadata, NFC

Further unify the handling of function-local metadata with global
metadata, by exposing the same interface in ValueEnumerator. Both
contexts use

BitcodeWriter: Further unify function metadata, NFC

Further unify the handling of function-local metadata with global
metadata, by exposing the same interface in ValueEnumerator. Both
contexts use the same accessors:

- getMDStrings(): get the strings for this block.
- getNonMDStrings(): get the non-strings for this block.

A future commit will start adding strings to the function-block.

llvm-svn: 265224

show more ...

Reverts r265219.

Unintentionally commited... time to call the day off!

From: Mehdi Amini <[email protected]>
llvm-svn: 265221

wip

From: Mehdi Amini <[email protected]>
llvm-svn: 265219

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 <[email protected]>
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 <[email protected]>
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 <[email protected]

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 <[email protected]>
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 <[email protected]>
llvm-svn: 265095

show more ...

Swift Calling Convention: add swiftself attribute.

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

llvm-svn: 264754

BitcodeWriter: Reuse writeMetadataRecords, NFC

Change writeFunctionMetadata to call writeMetadataRecords. For now
there's no functionality change, but makes it easy to serialize other
types of meta

BitcodeWriter: Reuse writeMetadataRecords, NFC

Change writeFunctionMetadata to call writeMetadataRecords. For now
there's no functionality change, but makes it easy to serialize other
types of metadata in the function block in the future.

llvm-svn: 264557

show more ...

BitcodeWriter: Rename some functions for consistency, NFC

To match writeMetadataRecords, writeNamedMetadata and
writeMetadataStrings, change:

WriteModuleMetadata => writeModuleMetadata

BitcodeWriter: Rename some functions for consistency, NFC

To match writeMetadataRecords, writeNamedMetadata and
writeMetadataStrings, change:

WriteModuleMetadata => writeModuleMetadata
WriteFunctionLocalMetadata => writeFunctionMetadata
Write##CLASS => write##CLASS

The only major change is "FunctionLocal" => "Function". The point is to
be less specific, in preparation for emitting normal metadata records
inside function metadata blocks (currently we only emit
`LocalAsMetadata` there).

llvm-svn: 264556

show more ...

BitcodeWriter: Split out writeMetadataRecords, NFC

Besides being a nice cleanup, this is preparation for reusing the code
in function metadata blocks.

llvm-svn: 264555

BitcodeWriter: Restructure WriteFunctionLocalMetadata, NFC

Use an early return to simplify logic.

llvm-svn: 264554

BitcodeWriter: Simplify tracking of function-local metadata, NFC

We don't really need a separate vector here; instead, point at a range
inside the main MDs array. This matches how r264551 reference

BitcodeWriter: Simplify tracking of function-local metadata, NFC

We don't really need a separate vector here; instead, point at a range
inside the main MDs array. This matches how r264551 references the
ranges of strings and non-strings.

llvm-svn: 264552

show more ...

Reapply ~"Bitcode: Collect all MDString records into a single blob"

Spiritually reapply commit r264409 (reverted in r264410), albeit with a
bit of a redesign.

Firstly, avoid splitting the big blob

Reapply ~"Bitcode: Collect all MDString records into a single blob"

Spiritually reapply commit r264409 (reverted in r264410), albeit with a
bit of a redesign.

Firstly, avoid splitting the big blob into multiple chunks of strings.

r264409 imposed an arbitrary limit to avoid a massive allocation on the
shared 'Record' SmallVector. The bug with that commit only reproduced
when there were more than "chunk-size" strings. A test for this would
have been useless long-term, since we're liable to adjust the chunk-size
in the future.

Thus, eliminate the motivation for chunk-ing by storing the string sizes
in the blob. Here's the layout:

vbr6: # of strings
vbr6: offset-to-blob
blob:
[vbr6]: string lengths
[char]: concatenated strings

Secondly, make the output of llvm-bcanalyzer readable.

I noticed when debugging r264409 that llvm-bcanalyzer was outputting a
massive blob all in one line. Past a small number, the strings were
impossible to split in my head, and the lines were way too long. This
version adds support in llvm-bcanalyzer for pretty-printing.

<STRINGS abbrevid=4 op0=3 op1=9/> num-strings = 3 {
'abc'
'def'
'ghi'
}

From the original commit:

Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this
should (a) slightly reduce bitcode size, since there is less record
overhead, and (b) greatly improve reading speed, since blobs are super
cheap to deserialize.

llvm-svn: 264551

show more ...