DebugInfo: New metadata representation for global variables.

This patch reverses the edge from DIGlobalVariable to GlobalVariable.
This will allow us to more easily preserve debug info metadata when

DebugInfo: New metadata representation for global variables.

This patch reverses the edge from DIGlobalVariable to GlobalVariable.
This will allow us to more easily preserve debug info metadata when
manipulating global variables.

Fixes PR30362. A program for upgrading test cases is attached to that
bug.

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

llvm-svn: 281284

show more ...

DebugInfo: Add flag to CU to disable emission of inline debug info into the skeleton CU

In cases where .dwo/.dwp files are guaranteed to be available, skipping
the extra online (in the .o file) inli

DebugInfo: Add flag to CU to disable emission of inline debug info into the skeleton CU

In cases where .dwo/.dwp files are guaranteed to be available, skipping
the extra online (in the .o file) inline info can save a substantial
amount of space - see the original r221306 for more details there.

llvm-svn: 279650

show more ...

Constify some path in the bitcode writer (NFC)

llvm-svn: 279211

Don't import variadic functions

Summary:
This patch adds IsVariadicFunction bit to summary in order
to not import variadic functions. Inliner doesn't inline
variadic functions because it is hard to

Don't import variadic functions

Summary:
This patch adds IsVariadicFunction bit to summary in order
to not import variadic functions. Inliner doesn't inline
variadic functions because it is hard to reason about it.

This one small fix improves Importer by about 16%
(going from 86% to 100% of imported functions that are
inlined anywhere)
on some spec benchmarks like 'int' and others.

Reviewers: eraman, mehdi_amini, tejohnson

Subscribers: mehdi_amini, llvm-commits

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

llvm-svn: 278432

show more ...

[ThinLTO] Address review comments from PGO indirect call promotion (NFC)

Address a couple of post-commit review comments from r275707.

llvm-svn: 275867

[ThinLTO] Perform profile-guided indirect call promotion

Summary:
To enable profile-guided indirect call promotion in ThinLTO mode, we
simply add call graph edges for each profitable target from the

[ThinLTO] Perform profile-guided indirect call promotion

Summary:
To enable profile-guided indirect call promotion in ThinLTO mode, we
simply add call graph edges for each profitable target from the profile
to the summaries, then the summary-guided importing will consider the
callee for importing as usual.

Also we need to enable the indirect call promotion pass creation in the
PassManagerBuilder when PerformThinLTO=true (we are in the ThinLTO
backend), so that the newly imported functions are considered for
promotion in the backends.

The IC promotion profiles refer to callees by GUID, which required
adding GUIDs to the per-module VST in bitcode (and assigning them
valueIds similar to how they are assigned valueIds in the combined
index).

Reviewers: mehdi_amini, xur

Subscribers: mehdi_amini, davidxl, llvm-commits

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

llvm-svn: 275707

show more ...

Add writeonly IR attribute

Summary:
This complements the earlier addition of IntrWriteMem and IntrWriteArgMem
LLVM intrinsic properties, see D18291.

Also start using the attribute for memset, memcp

Add writeonly IR attribute

Summary:
This complements the earlier addition of IntrWriteMem and IntrWriteArgMem
LLVM intrinsic properties, see D18291.

Also start using the attribute for memset, memcpy, and memmove intrinsics,
and remove their special-casing in BasicAliasAnalysis.

Reviewers: reames, joker.eph

Subscribers: joker.eph, llvm-commits

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

llvm-svn: 274485

show more ...

[codeview] Add DISubprogram::ThisAdjustment

Summary:
This represents the adjustment applied to the implicit 'this' parameter
in the prologue of a virtual method in the MS C++ ABI. The adjustment is

[codeview] Add DISubprogram::ThisAdjustment

Summary:
This represents the adjustment applied to the implicit 'this' parameter
in the prologue of a virtual method in the MS C++ ABI. The adjustment is
always zero unless multiple inheritance is involved.

This increases the size of DISubprogram by 8 bytes, unfortunately. The
adjustment really is a signed 32-bit integer. If this size increase is
too much, we could probably win it back by splitting out a subclass with
info specific to virtual methods (virtuality, vindex, thisadjustment,
containingType).

Reviewers: aprantl, dexonsmith

Subscribers: aaboud, amccarth, llvm-commits

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

llvm-svn: 274325

show more ...

BitcodeWriter: Remove redundant (and incorrect) check for whether to emit module summary.

The function name Module::empty() is slightly misleading in that it
only tests for the presence of functions

BitcodeWriter: Remove redundant (and incorrect) check for whether to emit module summary.

The function name Module::empty() is slightly misleading in that it
only tests for the presence of functions in the module. However we
still want to emit the module summary if the module contains only
global variables or aliases. The presence of such entities can be
determined simply by checking the summary directly, as we are doing
below.

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

llvm-svn: 273638

show more ...

IR: Allow metadata attachments on declarations, and fix lazy loaded metadata issue with globals.

This change is motivated by an upcoming change to the metadata representation
used for CFI. The indir

IR: Allow metadata attachments on declarations, and fix lazy loaded metadata issue with globals.

This change is motivated by an upcoming change to the metadata representation
used for CFI. The indirect function call checker needs type information for
external function declarations in order to correctly generate jump table
entries for such declarations. We currently associate such type information
with declarations using a global metadata node, but I plan [1] to move all
such metadata to global object attachments.

In bitcode, metadata attachments for function declarations appear in the
global metadata block. This seems reasonable to me because I expect metadata
attachments on declarations to be uncommon. In the long term I'd also expect
this to be the case for CFI, because we'd want to use some specialized bitcode
format for this metadata that could be read as part of the ThinLTO thin-link
phase, which would mean that it would not appear in the global metadata block.

To solve the lazy loaded metadata issue I was seeing with D20147, I use the
same bitcode representation for metadata attachments for global variables as I
do for function declarations. Since there's a use case for metadata attachments
in the global metadata block, we might as well use that representation for
global variables as well, at least until we have a mechanism for lazy loading
global variables.

In the assembly format, the metadata attachments appear after the "declare"
keyword in order to avoid a parsing ambiguity.

[1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html

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

llvm-svn: 273336

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

[DebugInfo] Add calling convention support for DWARF and CodeView

Summary:
Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum. If
it is present and non-zero, the backend will emit

[DebugInfo] Add calling convention support for DWARF and CodeView

Summary:
Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum. If
it is present and non-zero, the backend will emit it as a
DW_AT_calling_convention attribute. On the CodeView side, we translate
it to the appropriate enum for the LF_PROCEDURE record.

I added a new LLVM vendor specific enum to the list of DWARF calling
conventions. DWARF does not appear to attempt to standardize these, so I
assume it's OK to do this until we coordinate with GCC on how to emit
vectorcall convention functions.

Reviewers: dexonsmith, majnemer, aaboud, amccarth

Subscribers: mehdi_amini, llvm-commits

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

llvm-svn: 272197

show more ...

Add support for metadata attachments for global variables.

This patch adds an IR, assembly and bitcode representation for metadata
attachments for globals. Future patches will port existing features

Add support for metadata attachments for global variables.

This patch adds an IR, assembly and bitcode representation for metadata
attachments for globals. Future patches will port existing features to use
these new attachments.

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

llvm-svn: 271348

show more ...

Avoid temporary vector for sorting in BitcodeWriter

As suggested by Duncan, fixup for r269634 and r269635

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

ThinLTO: fix non-determinism in bitcode writing

Calls are initialized from a DenseMap. We can sort them using the
value id to recover some determinism during serialization.

From: mehdi_amini <mehdi

ThinLTO: fix non-determinism in bitcode writing

Calls are initialized from a DenseMap. We can sort them using the
value id to recover some determinism during serialization.

From: mehdi_amini <mehdi_amini@91177308-0d34-0410-b5e6-96231b3b80d8>
llvm-svn: 269638

show more ...

Revert "ThinLTO: fix non-determinism in bitcode writing"

This reverts commit r269634, bots are broken.

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

ThinLTO: fix another non-determinism in bitcode writing

GlobalVars Refs are initialized from a DenseSet. We can sort them
using the value id to recover some determinism during serialization.

From:

ThinLTO: fix another non-determinism in bitcode writing

GlobalVars Refs are initialized from a DenseSet. We can sort them
using the value id to recover some determinism during serialization.

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

show more ...

ThinLTO: fix non-determinism in bitcode writing

Calls are initialized from a DenseMap. We can sort them using the
value id to recover some determinism during serialization.

From: Mehdi Amini <mehdi

ThinLTO: fix non-determinism in bitcode writing

Calls are initialized from a DenseMap. We can sort them using the
value id to recover some determinism during serialization.

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

show more ...

ThinLTO: fix non-determinism in bitcode writing

Refs are initialized from a DenseSet. We can sort them using the
value id to recover some determinism during serialization.

From: Mehdi Amini <mehdi.

ThinLTO: fix non-determinism in bitcode writing

Refs are initialized from a DenseSet. We can sort them using the
value id to recover some determinism during serialization.

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

show more ...

Move helper classes into anonymous namespaces. NFC.

llvm-svn: 269591

[ThinLTO] Fix Windows debug failure in new iterator

This fixes a debug assert on Windows from the new iterator
implementation added in r269059. The Windows std::vector iterator
operator== checks in

[ThinLTO] Fix Windows debug failure in new iterator

This fixes a debug assert on Windows from the new iterator
implementation added in r269059. The Windows std::vector iterator
operator== checks in debug mode that the containers being iterated over
are the same, which they may not be.

Fixed by checking that we are iterating over the same container before
comparing the container iterators.

llvm-svn: 269232

show more ...

Restore "[ThinLTO] Emit individual index files for distributed backends"

This restores commit r268627:
Summary:
When launching ThinLTO backends in a distributed build (currently
supporte

Restore "[ThinLTO] Emit individual index files for distributed backends"

This restores commit r268627:
Summary:
When launching ThinLTO backends in a distributed build (currently
supported in gold via the thinlto-index-only plugin option), emit
an individual index file for each backend process as described here:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098272.html

...

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

Address msan failures by avoiding std::prev on map.end(), the
theory is that this is causing issues due to some known UB problems
in __tree.

llvm-svn: 269059

show more ...

Implement a safer bitcode upgrade for DISubprogram.

The bitcode upgrade I added for DISubprogram in r266446 was based on the
assumption that the CU node for the subprogram was already materialized b

Implement a safer bitcode upgrade for DISubprogram.

The bitcode upgrade I added for DISubprogram in r266446 was based on the
assumption that the CU node for the subprogram was already materialized by the
time the DISubprogram is visited. This assumption may not hold true as future
versions of LLVM may decide to write out bitcode in a different order. This
patch corrects this by introducing a versioning bit next to the distinct flag to
unambiguously differentiate the new from the old record layouts.

Note for people stabilizing LLVM out-of-tree: This patch introduces a bitcode
incompatibility with llvm trunk revisions from r266446 — this commit. (But
D19987 will ensure that it degrades gracefully).

http://reviews.llvm.org/D20004
rdar://problem/26074194

llvm-svn: 268816

show more ...

BitcodeWriter: Simplify. NFC.

llvm-svn: 268707

Revert "[ThinLTO] Emit individual index files for distributed backends"

MemorySanitizer: use-of-uninitialized-value in lib/Bitcode/Writer/BitcodeWriter.cpp:364:70
http://lab.llvm.org:8011/builders/s

Revert "[ThinLTO] Emit individual index files for distributed backends"

MemorySanitizer: use-of-uninitialized-value in lib/Bitcode/Writer/BitcodeWriter.cpp:364:70
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/12544/steps/check-llvm%20msan/logs/stdio

This reverts commit 0c4a898ea550699d1b2f4fe3767251c8f9a48d52.

llvm-svn: 268660

show more ...