[Assignment Tracking][3/*] Add DIAssignID metadata boilerplate

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way

[Assignment Tracking][3/*] Add DIAssignID metadata boilerplate

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir

Add the DIAssignID metadata attachment boilerplate. Includes a textual-bitcode
roundtrip test and tests that the verifier and parser catch badly formed IR.

This piece of metadata links together stores (used as an attachment) and the
yet-to-be-added llvm.dbg.assign debug intrinsic (used as an operand).

Reviewed By: jmorse

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

show more ...

Revert "[Assignment Tracking][3/*] Add DIAssignID metadata boilerplate"

This reverts commit c285df77e9b78f971f9cd9d025248c20b030cc2a.

A sanitizer bot found an issue:
https://lab.llvm.org/buildbot/#

Revert "[Assignment Tracking][3/*] Add DIAssignID metadata boilerplate"

This reverts commit c285df77e9b78f971f9cd9d025248c20b030cc2a.

A sanitizer bot found an issue:
https://lab.llvm.org/buildbot/#/builders/5/builds/28809/steps/13/logs/stdio

show more ...

[Assignment Tracking][3/*] Add DIAssignID metadata boilerplate

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way

[Assignment Tracking][3/*] Add DIAssignID metadata boilerplate

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir

Add the DIAssignID metadata attachment boilerplate. Includes a textual-bitcode
roundtrip test and tests that the verifier and parser catch badly formed IR.

This piece of metadata links together stores (used as an attachment) and the
yet-to-be-added llvm.dbg.assign debug intrinsic (used as an operand).

Reviewed By: jmorse

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

show more ...

[llvm] LLVM_FALLTHROUGH => [[fallthrough]]. NFC

With C++17 there is no Clang pedantic warning or MSVC C5051.

[Bitcode] Report metadata decoding error more gracefully

[Bitcode] Support expanding constant expressions into instructions

This implements an autoupgrade from constant expressions to
instructions, which is needed for
https://discourse.llvm.org/t/rfc-remo

[Bitcode] Support expanding constant expressions into instructions

This implements an autoupgrade from constant expressions to
instructions, which is needed for
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179.

The basic approach is that constant expressions (CST_CODE_CE_*
records) now initially only create a BitcodeConstant value that
holds opcode, flags and operands IDs. Then, when the value actually
gets used, it can be converted either into a constant expression
(if that expression type is still supported) or into a sequence of
instructions. As currently all expressions are still supported,
-expand-constant-exprs is added for testing purposes, to force
expansion.

PHI nodes require special handling, because the constant expression
needs to be evaluated on the incoming edge. We do this by putting
it into a temporary block and then wiring it up appropriately
afterwards (for non-critical edges, we could also move the
instructions into the predecessor).

This also removes the need for the forward referenced constants
machinery, as the BitcodeConstants only hold value IDs. At the
point where the value is actually materialized, no forward
references are needed anymore.

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

show more ...

[DebugInfo] Add a TargetFuncName field in DISubprogram for
specifying DW_AT_trampoline as a string. Also update the signature
of DIBuilder::createFunction to reflect this addition.

Differential Revi

[DebugInfo] Add a TargetFuncName field in DISubprogram for
specifying DW_AT_trampoline as a string. Also update the signature
of DIBuilder::createFunction to reflect this addition.

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

show more ...

DebugInfo: Make the simplified template names prefix more unique

DebugInfo: ThinLTO: Import template parameters on type declarations

Necessary when importing class template specializations that have
simplified template names (may otherwise be necessary - eg: Sony

DebugInfo: ThinLTO: Import template parameters on type declarations

Necessary when importing class template specializations that have
simplified template names (may otherwise be necessary - eg: Sony
requires template parameter DIEs even with unsimplified names, but short
of always importing names this is the best I can do for now) - long term
this probably needs a flag for the DICompositeType to specify whether it
needs template parameters on declarations & that flag could power this
behavior, rather than inspecting the name.

show more ...

[Bitcode] Store type IDs for values

This is the next step towards supporting bitcode auto upgrade with
opaque pointers. The ValueList now stores the Value* together with
its associated type ID, whic

[Bitcode] Store type IDs for values

This is the next step towards supporting bitcode auto upgrade with
opaque pointers. The ValueList now stores the Value* together with
its associated type ID, which allows inspecting the original pointer
element type of arbitrary values.

This is a largely mechanical change threading the type ID through
various places. I've left TODOTypeID placeholders in a number of
places where determining the type ID is either non-trivial or
requires allocating a new type ID not present in the original
bitcode. For this reason, the new type IDs are also not used for
anything yet (apart from propagation). They will get used once the
TODOs are resolved.

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

show more ...

[Bitcode] Fix size check for DIImportedEntity record

This was using && instead of ||.

Cleanup LLVMBitcode headers

Major user-facing changes:
llvm/Bitcode/BitcodeReader.h no longer includes llvm/IR/ModuleSummaryIndex.h

Some statistics:
clang++ -E -Iinclude -I../llvm/include ../llvm/

Cleanup LLVMBitcode headers

Major user-facing changes:
llvm/Bitcode/BitcodeReader.h no longer includes llvm/IR/ModuleSummaryIndex.h

Some statistics:
clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Bitcode/Reader/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
after: 493335
before: 539640

Discourse thread on the topic: https://discourse.llvm.org/t/include-what-you-use-include-cleanup/

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

show more ...

Reduce dependencies on llvm/BinaryFormat/Dwarf.h

This header is very large (3M Lines once expended) and was included in location
where dwarf-specific information were not needed.

More specifically,

Reduce dependencies on llvm/BinaryFormat/Dwarf.h

This header is very large (3M Lines once expended) and was included in location
where dwarf-specific information were not needed.

More specifically, this commit suppresses the dependencies on
llvm/BinaryFormat/Dwarf.h in two headers: llvm/IR/IRBuilder.h and
llvm/IR/DebugInfoMetadata.h. As these headers (esp. the former) are widely used,
this has a decent impact on number of preprocessed lines generated during
compilation of LLVM, as showcased below.

This is achieved by moving some definitions back to the .cpp file, no
performance impact implied[0].

As a consequence of that patch, downstream user may need to manually some extra
files:

llvm/IR/IRBuilder.h no longer includes llvm/BinaryFormat/Dwarf.h
llvm/IR/DebugInfoMetadata.h no longer includes llvm/BinaryFormat/Dwarf.h

In some situations, codes maybe relying on the fact that
llvm/BinaryFormat/Dwarf.h was including llvm/ADT/Triple.h, this hidden
dependency now needs to be explicit.

$ clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Transforms/Scalar/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
after: 10978519
before: 11245451

Related Discourse thread: https://llvm.discourse.group/t/include-what-you-use-include-cleanup
[0] https://llvm-compile-time-tracker.com/compare.php?from=fa7145dfbf94cb93b1c3e610582c495cb806569b&to=995d3e326ee1d9489145e20762c65465a9caeab4&stat=instructions

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

show more ...

[DebugInfo] Add stringLocationExp field to DIStringType

DIStringType is used to encode the debug info of a character object
in Fortran. A Fortran deferred-length character object is typically
implem

[DebugInfo] Add stringLocationExp field to DIStringType

DIStringType is used to encode the debug info of a character object
in Fortran. A Fortran deferred-length character object is typically
implemented as a pair of the following two pieces of info: An address
of the raw storage of the characters, and the length of the object.
The stringLocationExp field contains the DIExpression to get to the
raw storage.

This patch also enables the emission of DW_AT_data_location attribute
in a DW_TAG_string_type debug info entry based on stringLocationExp
in DIStringType.

A test is also added to ensure that the bitcode reader is backward
compatible with the old DIStringType format.

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

show more ...

[llvm] Fix bugprone argument comments (NFC)

Identified with bugprone-argument-comment.

[llvm] Use true/false instead of 1/0 (NFC)

Identified with modernize-use-bool-literals.

[LLVM][NFC]Inclusive language: remove occurances of sanity check/test from llvm

Part of work to use more inclusive language in clang/llvm. Rewording
some comments and change function and variable na

[LLVM][NFC]Inclusive language: remove occurances of sanity check/test from llvm

Part of work to use more inclusive language in clang/llvm. Rewording
some comments and change function and variable names.

show more ...

[llvm] Use isa instead of dyn_cast (NFC)

[DebugInfo] run clang-format on some unformatted files

This trivial patch runs clang-format on some unformatted files before
doing logic changes and prevent hard to review diffs.

Differential Revis

[DebugInfo] run clang-format on some unformatted files

This trivial patch runs clang-format on some unformatted files before
doing logic changes and prevent hard to review diffs.

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

show more ...

Revert "[DebugInfo] Enforce implicit constraints on `distinct` MDNodes"

This reverts commit ee7652569854af567ba83e5255d70e80cc8619a1.

Causes crashes, see comments in D104827.

[DebugInfo] Enforce implicit constraints on `distinct` MDNodes

Add UNIQUED and DISTINCT properties in Metadata.def and use them to
implement restrictions on the `distinct` property of MDNodes:

* DI

[DebugInfo] Enforce implicit constraints on `distinct` MDNodes

Add UNIQUED and DISTINCT properties in Metadata.def and use them to
implement restrictions on the `distinct` property of MDNodes:

* DIExpression can currently be parsed from IR or read from bitcode
as `distinct`, but this property is silently dropped when printing
to IR. This causes accepted IR to fail to round-trip. As DIExpression
appears inline at each use in the canonical form of IR, it cannot
actually be `distinct` anyway, as there is no syntax to describe it.
* Similarly, DIArgList is conceptually always uniqued. It is currently
restricted to only appearing in contexts where there is no syntax for
`distinct`, but for consistency it is treated equivalently to
DIExpression in this patch.
* DICompileUnit is already restricted to always being `distinct`, but
along with adding general support for the inverse restriction I went
ahead and described this in Metadata.def and updated the parser to be
general. Future nodes which have this restriction can share this
support.

The new UNIQUED property applies to DIExpression and DIArgList, and
forbids them to be `distinct`. It also implies they are canonically
printed inline at each use, rather than via MDNode ID.

The new DISTINCT property applies to DICompileUnit, and requires it to
be `distinct`.

A potential alternative change is to forbid the non-inline syntax for
DIExpression entirely, as is done with DIArgList implicitly by requiring
it appear in the context of a function. For example, we would forbid:

!named = !{!0}
!0 = !DIExpression()

Instead we would only accept the equivalent inlined version:

!named = !{!DIExpression()}

This essentially removes the ability to create a `distinct` DIExpression
by construction, as there is no syntax for `distinct` inline. If this
patch is accepted as-is, the result would be that the non-canonical
version is accepted, but the following would be an error and produce a diagnostic:

!named = !{!0}
; error: 'distinct' not allowed for !DIExpression()
!0 = distinct !DIExpression()

Also update some documentation to consistently use the inline syntax for
DIExpression, and to describe the restrictions on `distinct` for nodes
where applicable.

Reviewed By: StephenTozer, t-tye

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

show more ...

Bitcode: Use Expected<T>::takeError() and moveInto() more, NFC

Avoid naming some Expected<T> values in the Bitcode reader by using
takeError() and moveInto() more often. This follows the smaller set

Bitcode: Use Expected<T>::takeError() and moveInto() more, NFC

Avoid naming some Expected<T> values in the Bitcode reader by using
takeError() and moveInto() more often. This follows the smaller set of
changes included in 2410fb4616b2c08bbaddd44e6c11da8285fbd1d3.

show more ...

[IR] Refactor GlobalIFunc to inherit from GlobalObject, Remove GlobalIndirectSymbol

As discussed in:
* https://reviews.llvm.org/D94166
* https://lists.llvm.org/pipermail/llvm-dev/2020-September/1450

[IR] Refactor GlobalIFunc to inherit from GlobalObject, Remove GlobalIndirectSymbol

As discussed in:
* https://reviews.llvm.org/D94166
* https://lists.llvm.org/pipermail/llvm-dev/2020-September/145031.html

The GlobalIndirectSymbol class lost most of its meaning in
https://reviews.llvm.org/D109792, which disambiguated getBaseObject
(now getAliaseeObject) between GlobalIFunc and everything else.
In addition, as long as GlobalIFunc is not a GlobalObject and
getAliaseeObject returns GlobalObjects, a GlobalAlias whose aliasee
is a GlobalIFunc cannot currently be modeled properly. Creating
aliases for GlobalIFuncs does happen in the wild (e.g. glibc). In addition,
calling getAliaseeObject on a GlobalIFunc will currently return nullptr,
which is undesirable because it should return the object itself for
non-aliases.

This patch refactors the GlobalIFunc class to inherit directly from
GlobalObject, and removes GlobalIndirectSymbol (while inlining the
relevant parts into GlobalAlias and GlobalIFunc). This allows for
calling getAliaseeObject() on a GlobalIFunc to return the GlobalIFunc
itself, making getAliaseeObject() more consistent and enabling
alias-to-ifunc to be properly modeled in the IR.

I exercised some judgement in the API clients of GlobalIndirectSymbol:
some were 'monomorphized' for GlobalAlias and GlobalIFunc, and
some remained shared (with the type adapted to become GlobalValue).

Reviewed By: MaskRay

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

show more ...

[llvm] Replace report_fatal_error(std::string) uses with report_fatal_error(Twine)

As described on D111049, we're trying to remove the <string> dependency from error handling and replace uses of rep

[llvm] Replace report_fatal_error(std::string) uses with report_fatal_error(Twine)

As described on D111049, we're trying to remove the <string> dependency from error handling and replace uses of report_fatal_error(const std::string&) with the Twine() variant which can be forward declared.

show more ...

[DebugInfo] Enhance DIImportedEntity to accept children entities

New field `elements` is added to '!DIImportedEntity', representing
list of aliased entities.
This is needed to dump optimized debuggi

[DebugInfo] Enhance DIImportedEntity to accept children entities

New field `elements` is added to '!DIImportedEntity', representing
list of aliased entities.
This is needed to dump optimized debugging information where all names
in a module are imported, but a few names are imported with overriding
aliases.

Reviewed By: dblaikie

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

show more ...