[BitcodeReader] Remove two unused variables

Revert "Reland "[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)" (2)"

This reverts commit cb9ac7051589ea0d05507f9370d0716bef86b4ae.
It causes an assert in clan

Revert "Reland "[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)" (2)"

This reverts commit cb9ac7051589ea0d05507f9370d0716bef86b4ae.
It causes an assert in clang:
virtual void llvm::DwarfDebug::endFunctionImpl(const llvm::MachineFunction*): Assertion `LScopes.getAbstractScopesList().size() == NumAbstractSubprograms && "getOrCreateAbstractScope() inserted an abstract subprogram scope"' failed.
https://bugs.chromium.org/p/chromium/issues/detail?id=1456288#c2

show more ...

Reland "[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)" (2)

Test "local-type-as-template-parameter.ll" is now enabled only for
x86_64.

Authored-by: Kristina

Reland "[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)" (2)

Test "local-type-as-template-parameter.ll" is now enabled only for
x86_64.

Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>

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

Depends on D144005

show more ...

Revert "Reland "[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)""

This reverts commit 2da45172c4bcd42f704c57c656926f56f32fc5ce.
Test local-type-as-template-par

Revert "Reland "[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)""

This reverts commit 2da45172c4bcd42f704c57c656926f56f32fc5ce.
Test local-type-as-template-parameter.ll fails on ppc64-aix.

show more ...

Reland "[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)"

Test "local-type-as-template-parameter.ll" now requires linux-system.

Authored-by: Kristina Bessonova

Reland "[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)"

Test "local-type-as-template-parameter.ll" now requires linux-system.

Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>

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

Depends on D144005

show more ...

Revert "[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)"

This reverts commit 66511b401042f28c74d2ded3aac76d19a53bd7c4.
llvm/test/DebugInfo/Generic/local-type-a

Revert "[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)"

This reverts commit 66511b401042f28c74d2ded3aac76d19a53bd7c4.
llvm/test/DebugInfo/Generic/local-type-as-template-parameter.ll is
broken.

show more ...

[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-loc

[DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (4/7)

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544

Similar to imported declarations, the patch tracks function-local types in
DISubprogram's 'retainedNodes' field. DwarfDebug is adjusted in accordance with
the aforementioned metadata change and provided a support of function-local
types scoped within a lexical block.

The patch assumes that DICompileUnit's 'enums field' no longer tracks local
types and DwarfDebug would assert if any locally-scoped types get placed there.

Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>

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

Depends on D144005

show more ...

Reland "[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)"

Got rid of non-determinism in MetadataLoader.cpp.

Authored-by: Kristina Bessonova <kbessonova@access

Reland "[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)"

Got rid of non-determinism in MetadataLoader.cpp.

Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>

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

show more ...

Revert "Reland "[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)""

This reverts commit fcc3981626821addc6c77b98006d02030b8ceb7f,
since Bitcode-upgrading code d

Revert "Reland "[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)""

This reverts commit fcc3981626821addc6c77b98006d02030b8ceb7f,
since Bitcode-upgrading code doesn't seem to be deterministic.

show more ...

Reland "[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)"

Run split-dwarf-local-impor3.ll only on x86_64-linux.

Revert "[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)"

This reverts commit d80fdc6fc1a6e717af1bcd7a7313e65de433ba85.
split-dwarf-local-impor3.ll fails becau

Revert "[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)"

This reverts commit d80fdc6fc1a6e717af1bcd7a7313e65de433ba85.
split-dwarf-local-impor3.ll fails because of an issue with
Dwo sections emission on Windows platform.

show more ...

[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-lo

[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544

Fixed PR51501 (tests from D112337).

1. Reuse of DISubprogram's 'retainedNodes' to track other function-local
entities together with local variables and labels (this patch cares about
function-local import while D144006 and D144008 use the same approach for
local types and static variables). So, effectively this patch moves ownership
of tracking local import from DICompileUnit's 'imports' field to DISubprogram's
'retainedNodes' and adjusts DWARF emitter for the new layout. The old layout
is considered unsupported (DwarfDebug would assert on such debug metadata).

DICompileUnit's 'imports' field is supposed to track global imported
declarations as it does before.

This addresses various FIXMEs and simplifies the next part of the patch.

2. Postpone emission of function-local imported entities from
`DwarfDebug::endFunctionImpl()` to `DwarfDebug::endModule()`.
While in `DwarfDebug::endFunctionImpl()` we do not have all the
information about a parent subprogram or a referring subprogram
(whether a subprogram inlined or not), so we can't guarantee we emit
an imported entity correctly and place it in a proper subprogram tree.
So now, we just gather needed details about the import itself and its
parent entity (either a Subprogram or a LexicalBlock) during
processing in `DwarfDebug::endFunctionImpl()`, but all the real work is
done in `DwarfDebug::endModule()` when we have all the required
information to make proper emission.

Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>

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

show more ...

Revert "[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)"

This reverts commit ed578f02cf44a52adde16647150e7421f3ef70f3.

Tests llvm/test/DebugInfo/Generic/spli

Revert "[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)"

This reverts commit ed578f02cf44a52adde16647150e7421f3ef70f3.

Tests llvm/test/DebugInfo/Generic/split-dwarf-local-import*.ll fail
when x86_64 target is not registered.

show more ...

[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-lo

[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544

Fixed PR51501 (tests from D112337).

1. Reuse of DISubprogram's 'retainedNodes' to track other function-local
entities together with local variables and labels (this patch cares about
function-local import while D144006 and D144008 use the same approach for
local types and static variables). So, effectively this patch moves ownership
of tracking local import from DICompileUnit's 'imports' field to DISubprogram's
'retainedNodes' and adjusts DWARF emitter for the new layout. The old layout
is considered unsupported (DwarfDebug would assert on such debug metadata).

DICompileUnit's 'imports' field is supposed to track global imported
declarations as it does before.

This addresses various FIXMEs and simplifies the next part of the patch.

2. Postpone emission of function-local imported entities from
`DwarfDebug::endFunctionImpl()` to `DwarfDebug::endModule()`.
While in `DwarfDebug::endFunctionImpl()` we do not have all the
information about a parent subprogram or a referring subprogram
(whether a subprogram inlined or not), so we can't guarantee we emit
an imported entity correctly and place it in a proper subprogram tree.
So now, we just gather needed details about the import itself and its
parent entity (either a Subprogram or a LexicalBlock) during
processing in `DwarfDebug::endFunctionImpl()`, but all the real work is
done in `DwarfDebug::endModule()` when we have all the required
information to make proper emission.

Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>

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

show more ...

Revert "[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)"

This reverts commit d04452d54829cd7af5b43d670325ffa755ab0030 since
test llvm-project/llvm/test/Bitcod

Revert "[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)"

This reverts commit d04452d54829cd7af5b43d670325ffa755ab0030 since
test llvm-project/llvm/test/Bitcode/DIImportedEntity_backward.ll is broken.

show more ...

[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-lo

[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544

Fixed PR51501 (tests from D112337).

1. Reuse of DISubprogram's 'retainedNodes' to track other function-local
entities together with local variables and labels (this patch cares about
function-local import while D144006 and D144008 use the same approach for
local types and static variables). So, effectively this patch moves ownership
of tracking local import from DICompileUnit's 'imports' field to DISubprogram's
'retainedNodes' and adjusts DWARF emitter for the new layout. The old layout
is considered unsupported (DwarfDebug would assert on such debug metadata).

DICompileUnit's 'imports' field is supposed to track global imported
declarations as it does before.

This addresses various FIXMEs and simplifies the next part of the patch.

2. Postpone emission of function-local imported entities from
`DwarfDebug::endFunctionImpl()` to `DwarfDebug::endModule()`.
While in `DwarfDebug::endFunctionImpl()` we do not have all the
information about a parent subprogram or a referring subprogram
(whether a subprogram inlined or not), so we can't guarantee we emit
an imported entity correctly and place it in a proper subprogram tree.
So now, we just gather needed details about the import itself and its
parent entity (either a Subprogram or a LexicalBlock) during
processing in `DwarfDebug::endFunctionImpl()`, but all the real work is
done in `DwarfDebug::endModule()` when we have all the required
information to make proper emission.

Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>

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

show more ...

[BitcodeReader] Allow reading pointer types from old IR

When opaque pointers are enabled and old IR with typed pointers is read,
the BitcodeReader automatically upgrades all typed pointers to opaque

[BitcodeReader] Allow reading pointer types from old IR

When opaque pointers are enabled and old IR with typed pointers is read,
the BitcodeReader automatically upgrades all typed pointers to opaque
pointers. This is a lossy conversion, i.e. when a function argument is a
pointer and unused, it’s impossible to reconstruct the original type
behind the pointer.

There are cases where the type information of pointers is needed. One is
reading DXIL, which is bitcode of old LLVM IR and makes a lot of use of
pointers in function signatures.
We’d like to keep using up-to-date llvm to read in and process DXIL, so
in the face of opaque pointers, we need some way to access the type
information of pointers from the read bitcode.

This patch allows extracting type information by supplying functions to
parseBitcodeFile that get called for each function signature or metadata
value. The function can access the type information via the reader’s
type IDs and the getTypeByID and getContainedTypeID functions.
The tests exemplarily shows how type info from pointers can be stored in
metadata for use after the BitcodeReader finished.

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

show more ...

Revert "[BitcodeReader] Allow reading pointer types from old IR"

This reverts commit b56df190b01335506ce30a4559d880da76d1a181.

The unit tests are implemented in a way that requires support for
writ

Revert "[BitcodeReader] Allow reading pointer types from old IR"

This reverts commit b56df190b01335506ce30a4559d880da76d1a181.

The unit tests are implemented in a way that requires support for
writing typed pointer bitcode, which is going away soon. Please
rewrite it in a way that not have requirement, e.g. by shipping
pre-compiled bitcode, as we do for integration tests.

show more ...

[BitcodeReader] Allow reading pointer types from old IR

When opaque pointers are enabled and old IR with typed pointers is read,
the BitcodeReader automatically upgrades all typed pointers to opaque

[BitcodeReader] Allow reading pointer types from old IR

When opaque pointers are enabled and old IR with typed pointers is read,
the BitcodeReader automatically upgrades all typed pointers to opaque
pointers. This is a lossy conversion, i.e. when a function argument is a
pointer and unused, it’s impossible to reconstruct the original type
behind the pointer.

There are cases where the type information of pointers is needed. One is
reading DXIL, which is bitcode of old LLVM IR and makes a lot of use of
pointers in function signatures.
We’d like to keep using up-to-date llvm to read in and process DXIL, so
in the face of opaque pointers, we need some way to access the type
information of pointers from the read bitcode.

This patch allows extracting type information by supplying functions to
parseBitcodeFile that get called for each function signature or metadata
value. The function can access the type information via the reader’s
type IDs and the getTypeByID and getContainedTypeID functions.
The tests exemplarily shows how type info from pointers can be stored in
metadata for use after the BitcodeReader finished.

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

show more ...

Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ part

Use deduction guides instead of helper functions.

The only non-automatic changes have been:

1. ArrayRef(some_uint8_pointer, 0

Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ part

Use deduction guides instead of helper functions.

The only non-automatic changes have been:

1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).

Per reviewers' comment, some useless makeArrayRef have been removed in the process.

This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.

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

show more ...

Don't include None.h (NFC)

I've converted all known uses of None to std::nullopt, so we no longer
need to include None.h.

This is part of an effort to migrate from llvm::Optional to
std::optional:

Don't include None.h (NFC)

I've converted all known uses of None to std::nullopt, so we no longer
need to include None.h.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[DebugInfo] Store optional DIFile::Source as pointer

getCanonicalMDString() also returns a nullptr for empty strings, which
tripped over the getSource() method. Solve the ambiguity of no source
vers

[DebugInfo] Store optional DIFile::Source as pointer

getCanonicalMDString() also returns a nullptr for empty strings, which
tripped over the getSource() method. Solve the ambiguity of no source
versus an optional containing a nullptr by simply storing a pointer.

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

show more ...

[llvm] Don't include Optional.h (NFC)

These source files no longer use Optional<T>, so they do not need to
include Optional.h.

This is part of an effort to migrate from llvm::Optional to
std::optio

[llvm] Don't include Optional.h (NFC)

These source files no longer use Optional<T>, so they do not need to
include Optional.h.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

DebugInfoMetadata: convert Optional to std::optional

[Bitcode] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of

[Bitcode] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...