Align definition of DW_OP_plus with DWARF spec [3/3]

Summary:
This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things.

The

Align definition of DW_OP_plus with DWARF spec [3/3]

Summary:
This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things.

The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack.

This is done in three stages:
• The first patch (LLVM) adds support for DW_OP_plus_uconst.
• The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst.
• The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions.

Patch by Sander de Smalen.

Reviewers: echristo, pcc, aprantl

Reviewed By: aprantl

Subscribers: fhahn, javed.absar, aprantl, llvm-commits

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

llvm-svn: 305386

show more ...

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.

I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.

This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.

Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).

llvm-svn: 304787

show more ...

[MetadataLoader] Remove unused Vector. NFCI.

llvm-svn: 303196

Remove line and file from DINamespace.

Fixes the issue highlighted in
http://lists.llvm.org/pipermail/cfe-dev/2014-June/037500.html.

The DW_AT_decl_file and DW_AT_decl_line attributes on namespaces

Remove line and file from DINamespace.

Fixes the issue highlighted in
http://lists.llvm.org/pipermail/cfe-dev/2014-June/037500.html.

The DW_AT_decl_file and DW_AT_decl_line attributes on namespaces can
prevent LLVM from uniquing types that are in the same namespace. They
also don't carry any meaningful information.

rdar://problem/17484998
Differential Revision: https://reviews.llvm.org/D32648

llvm-svn: 301706

show more ...

Turn DISubprogram into a variable-length node.

DISubprogram currently has 10 pointer operands, several of which are
often nullptr. This patch reduces the amount of memory allocated by
DISubprogram b

Turn DISubprogram into a variable-length node.

DISubprogram currently has 10 pointer operands, several of which are
often nullptr. This patch reduces the amount of memory allocated by
DISubprogram by rearranging the operands such that containing type,
template params, and thrown types come last, and are only allocated
when they are non-null (or followed by non-null operands).

This patch also eliminates the entirely unused DisplayName operand.

This saves up to 4 pointer operands per DISubprogram. (I tried
measuring the effect on peak memory usage on an LTO link of an X86
llc, but the results were very noisy).

This reapplies r301498 with an attempted workaround for g++.

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

llvm-svn: 301501

show more ...

Revert "Turn DISubprogram into a variable-length node."

This reverts commit r301498 while investigating bot breakage.

llvm-svn: 301499

Turn DISubprogram into a variable-length node.

DISubprogram currently has 10 pointer operands, several of which are
often nullptr. This patch reduces the amount of memory allocated by
DISubprogram b

Turn DISubprogram into a variable-length node.

DISubprogram currently has 10 pointer operands, several of which are
often nullptr. This patch reduces the amount of memory allocated by
DISubprogram by rearranging the operands such that containing type,
template params, and thrown types come last, and are only allocated
when they are non-null (or followed by non-null operands).

This patch also eliminates the entirely unused DisplayName operand.

This saves up to 4 pointer operands per DISubprogram. (I tried
measuring the effect on peak memory usage on an LTO link of an X86
llc, but the results were very noisy).

llvm-svn: 301498

show more ...

Add support for DW_TAG_thrown_type.

For Swift we would like to be able to encode the error types that a
function may throw, so the debugger can display them alongside the
function's return value whe

Add support for DW_TAG_thrown_type.

For Swift we would like to be able to encode the error types that a
function may throw, so the debugger can display them alongside the
function's return value when finish-ing a function.

DWARF defines DW_TAG_thrown_type (intended to be used for C++ throw()
declarations) that is a perfect fit for this purpose. This patch wires
up support for DW_TAG_thrown_type in LLVM by adding a list of thrown
types to DISubprogram.

To offset the cost of the extra pointer, there is a follow-up patch
that turns DISubprogram into a variable-length node.

rdar://problem/29481673

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

llvm-svn: 301489

show more ...

PR32382: Fix emitting complex DWARF expressions.

The DWARF specification knows 3 kinds of non-empty simple location
descriptions:
1. Register location descriptions
- describe a variable in a regis

PR32382: Fix emitting complex DWARF expressions.

The DWARF specification knows 3 kinds of non-empty simple location
descriptions:
1. Register location descriptions
- describe a variable in a register
- consist of only a DW_OP_reg
2. Memory location descriptions
- describe the address of a variable
3. Implicit location descriptions
- describe the value of a variable
- end with DW_OP_stack_value & friends

The existing DwarfExpression code is pretty much ignorant of these
restrictions. This used to not matter because we only emitted very
short expressions that we happened to get right by accident. This
patch makes DwarfExpression aware of the rules defined by the DWARF
standard and now chooses the right kind of location description for
each expression being emitted.

This would have been an NFC commit (for the existing testsuite) if not
for the way that clang describes captured block variables. Based on
how the previous code in LLVM emitted locations, DW_OP_deref
operations that should have come at the end of the expression are put
at its beginning. Fixing this means changing the semantics of
DIExpression, so this patch bumps the version number of DIExpression
and implements a bitcode upgrade.

There are two major changes in this patch:

I had to fix the semantics of dbg.declare for describing function
arguments. After this patch a dbg.declare always takes the *address*
of a variable as the first argument, even if the argument is not an
alloca.

When lowering a DBG_VALUE, the decision of whether to emit a register
location description or a memory location description depends on the
MachineLocation — register machine locations may get promoted to
memory locations based on their DIExpression. (Future) optimization
passes that want to salvage implicit debug location for variables may
do so by appending a DW_OP_stack_value. For example:
DBG_VALUE, [RBP-8] --> DW_OP_fbreg -8
DBG_VALUE, RAX --> DW_OP_reg0 +0
DBG_VALUE, RAX, DIExpression(DW_OP_deref) --> DW_OP_reg0 +0

All testcases that were modified were regenerated from clang. I also
added source-based testcases for each of these to the debuginfo-tests
repository over the last week to make sure that no synchronized bugs
slip in. The debuginfo-tests compile from source and run the debugger.

https://bugs.llvm.org/show_bug.cgi?id=32382
<rdar://problem/31205000>

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

llvm-svn: 300522

show more ...

Spelling mistakes in comments. NFCI.

Based on corrections mentioned in patch for clang for PR27635

llvm-svn: 299072

[DebugInfo] Emit address space with DW_AT_address_class attribute for pointer and reference types

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

llvm-svn: 297320

Move symbols from the global namespace into (anonymous) namespaces. NFC.

llvm-svn: 294837

Fix bitcode upgrade for DIGlobalVariables with a var: field.

This is a follow-up to https://reviews.llvm.org/D29349. It turns out
that NeedUpgradeToDIGlobalVariableExpression is always necessary wh

Fix bitcode upgrade for DIGlobalVariables with a var: field.

This is a follow-up to https://reviews.llvm.org/D29349. It turns out
that NeedUpgradeToDIGlobalVariableExpression is always necessary when
we encountered a version==0 record because it may always be referenced
via a list of globals in a DICompileUnit. My tests weren't good enough
to catch this though. To trigger this case, we need much older bitcode
produced by LLVM around version 3.7.

<rdar://problem/30404262>

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

llvm-svn: 294488

show more ...

Fix the bitcode upgrade for DIGlobalVariable in a DIImportedEntity context.

The bitcode upgrade for DIGlobalVariable unconditionally wrapped
DIGlobalVariables in a DIGlobalVariableExpression. When a

Fix the bitcode upgrade for DIGlobalVariable in a DIImportedEntity context.

The bitcode upgrade for DIGlobalVariable unconditionally wrapped
DIGlobalVariables in a DIGlobalVariableExpression. When a
DIGlobalVariable is referenced by a DIImportedEntity, however, this is
wrong. This patch fixes the bitcode upgrade by deferring the creation
of DIGlobalVariableExpressions until we know the context of the
DIGlobalVariable.

<rdar://problem/30134279>

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

llvm-svn: 294318

show more ...

Change debug-info-for-profiling from a TargetOption to a function attribute.

Summary: LTO requires the debug-info-for-profiling to be a function attribute.

Reviewers: echristo, mehdi_amini, dblaiki

Change debug-info-for-profiling from a TargetOption to a function attribute.

Summary: LTO requires the debug-info-for-profiling to be a function attribute.

Reviewers: echristo, mehdi_amini, dblaikie, probinson, aprantl

Reviewed By: mehdi_amini, dblaikie, aprantl

Subscribers: aprantl, probinson, ahatanak, llvm-commits, mehdi_amini

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

llvm-svn: 293833

show more ...

Avoid using unspecified ordering in MetadataLoader::MetadataLoaderImpl::parseOneMetadata.

Summary:
MetadataLoader::MetadataLoaderImpl::parseOneMetadata uses
the following construct in a number of pl

Avoid using unspecified ordering in MetadataLoader::MetadataLoaderImpl::parseOneMetadata.

Summary:
MetadataLoader::MetadataLoaderImpl::parseOneMetadata uses
the following construct in a number of places:

```
MetadataList.assignValue(<...>, NextMetadataNo++);
```

There, NextMetadataNo gets incremented, and since the order
of arguments evaluation is not specified, that can happen
before or after other arguments are evaluated.

In a few cases the other arguments indirectly use NextMetadataNo.
For instance, it's

```
MetadataList.assignValue(
GET_OR_DISTINCT(DIModule,
(Context, getMDOrNull(Record[1]),
getMDString(Record[2]), getMDString(Record[3]),
getMDString(Record[4]), getMDString(Record[5]))),
NextMetadataNo++);
```

getMDOrNull calls getMD that uses NextMetadataNo:

```
MetadataList.getMetadataFwdRef(NextMetadataNo);
```

Therefore, the order of evaluation becomes important. That caused
a very subtle LLD crash that only happens if compiled with GCC or
if LLD is built with LTO. In the case if LLD is compiled with Clang
and regular linking mode, everything worked as intended.

This change extracts incrementing of NextMetadataNo outside of
the arguments list to guarantee the correct order of evaluation.

For the record, this has taken 3 days to track to the origin. It all
started with a ThinLTO bot in Chrome not being able to link a target
if debug info is enabled.

Reviewers: pcc, mehdi_amini

Reviewed By: mehdi_amini

Subscribers: aprantl, llvm-commits

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

llvm-svn: 293291

show more ...

[ThinLTO] Fix lazy-loading of MDString instruction attachments

CFI is using intrinsics that takes MDString as arguments, and this
was broken during lazy-loading of metadata.

Differential Revision:

[ThinLTO] Fix lazy-loading of MDString instruction attachments

CFI is using intrinsics that takes MDString as arguments, and this
was broken during lazy-loading of metadata.

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

llvm-svn: 292641

show more ...

Add an assertion to PlaceholderQueue destructor, ensuring it has been flushed

llvm-svn: 292597

[ThinLTO] Add a recursive step in Metadata lazy-loading

Summary:
Without this, we're stressing the RAUW of unique nodes,
which is a costly operation. This is intended to limit
the number of RAUW, an

[ThinLTO] Add a recursive step in Metadata lazy-loading

Summary:
Without this, we're stressing the RAUW of unique nodes,
which is a costly operation. This is intended to limit
the number of RAUW, and is very effective on the total
link-time of opt with ThinLTO, before:

real 4m4.587s user 15m3.401s sys 0m23.616s

after:

real 3m25.261s user 12m22.132s sys 0m24.152s

Reviewers: tejohnson, pcc

Subscribers: llvm-commits

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

llvm-svn: 292420

show more ...

Apply clang-tidy's performance-unnecessary-value-param to LLVM.

With some minor manual fixes for using function_ref instead of
std::function. No functional change intended.

llvm-svn: 291904

[ThinLTO] Fix lazy-loading of Metadata attachment, which left some Fwd ref behind

The change in r291362 was too agressive. We still need to flush at the
end of the block because function local metad

[ThinLTO] Fix lazy-loading of Metadata attachment, which left some Fwd ref behind

The change in r291362 was too agressive. We still need to flush at the
end of the block because function local metadata can introduce fwd
ref as well.
(Bootstrap with ThinLTO was broken)

llvm-svn: 291379

show more ...

[ThinLTO] Fix assertions on lazy-loading of Metadata TBAA attachments

Summary:
The issue happens with:

%0 = ....., !tbaa !0
%1 = ....., !tbaa !1

With !0 that references !1.

In this case when lo

[ThinLTO] Fix assertions on lazy-loading of Metadata TBAA attachments

Summary:
The issue happens with:

%0 = ....., !tbaa !0
%1 = ....., !tbaa !1

With !0 that references !1.

In this case when loading !0 we generates a temporary for the
operand !1. We now flush it immediately and trigger the load of
!1 before moving on. If we don't we get the temporary when
attaching to %1. This is usually not an issue except that we
eagerly try to update TBAA MDNodes, which is obviously not possible
if we only have a temporary.

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

llvm-svn: 291362

show more ...

[Bitcode] Remove unused PlaceHolder parameter to lazyLoadModuleMetadataBlock()

llvm-svn: 291356

Use lazy-loading of Metadata in MetadataLoader when importing is enabled (NFC)

Summary:
This is a relatively simple scheme: we use the index emitted in the
bitcode to avoid loading all the global me

Use lazy-loading of Metadata in MetadataLoader when importing is enabled (NFC)

Summary:
This is a relatively simple scheme: we use the index emitted in the
bitcode to avoid loading all the global metadata. Instead we load
the index with their position in the bitcode so that we can load each
of them individually. Materializing the global metadata block in this
condition only triggers loading the named metadata, and the ones
referenced from there (transitively). When materializing a function,
metadata from the global block are loaded lazily as they are
referenced.

Two main current limitations are:

1) Global values other than functions are not materialized on demand,
so we need to eagerly load METADATA_GLOBAL_DECL_ATTACHMENT records
(and their transitive dependencies).
2) When we load a single metadata, we don't recurse on the operands,
instead we use a placeholder or a temporary metadata. Unfortunately
tepmorary nodes are very expensive. This is why we don't have it
always enabled and only for importing.

These two limitations can be lifted in a subsequent improvement if
needed.

With this change, the total link time of opt with ThinLTO and Debug
Info enabled is going down from 282s to 224s (~20%).

Reviewers: pcc, tejohnson, dexonsmith

Subscribers: llvm-commits

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

llvm-svn: 291027

show more ...

[ThinLTO] Import type as decl only when non-null Identifier

As per post-commit review for r289993 (D27775), we can only safely
import a type as a decl if it has an Identifier, as the Name alone
is n

[ThinLTO] Import type as decl only when non-null Identifier

As per post-commit review for r289993 (D27775), we can only safely
import a type as a decl if it has an Identifier, as the Name alone
is not enough to be unique across modules.

llvm-svn: 290915

show more ...