…inlined functions (#75385)"

This reverts commit fc6faa1.

…subprogram DIEs

With this change, construction of abstract subprogram DIEs is split in two stages/functions:
creation of DIE (in DwarfCompileUnit::getOrCreateAbstractSubprogramDIE) and its population
with children (in DwarfCompileUnit::constructAbstractSubprogramScopeDIE).
With that, abstract subprograms can be created/referenced from DwarfDebug::beginModule, which
should solve the issue with static local variables DIE creation of inlined functons
with optimized-out definitions. It fixes llvm#29985.

LexicalScopes class now stores mapping from DISubprograms to their corresponding llvm::Function's.
It is supposed to be built before processing of each function (so, now it has a method for "module
initialization" alongside the method for "function initialization"). It is used by DwarfCompileUnit
to determine whether a DISubprogram needs an abstract DIE before DwarfDebug::beginFunction is invoked.

DwarfCompileUnit::getOrCreateSubprogramDIE method is added, which can create an abstract or a concrete
DIE for a subprogram. It accepts llvm::Function* argument to determine whether a concrete DIE must be created.

This is a temporary fix for llvm#29985. Ideally, it will be fixed by
moving global variables and types emission to DwarfDebug::endModule (https://reviews.llvm.org/D144007, https://reviews.llvm.org/D144005).
However, I'm not sure if these patches can be merged before llvm#75385.
The last attempt to make it mergeable was llvm#142166.
@dwblaikie came up with an idea of making DISubprograms unique in LLVM IR. To implement that,
I've tried making a patch that allows DwarfDebug to handle multiple llvm::Functions referring
to the same DISubprogram, and it also needs parts of the functionality of this patch.

Some changes made by @ellishg in llvm#90523 were taken for this commit.

…o multiple Functions

Depends on:
* TODO

In llvm#75385 (and the following
tries), an attempt was made, to support attaching local types to
DILocalScopes, and to store function local types in DISubprogram's
`retainedNodes:` field.

That patch failed to land due to issues arising during LTO process.
If two definition DISubprograms from different compile units
represent, essentially, the same source code function, and have
common local DICompositeType, and if this DICompositeType is uniqued
(due to ODRUniquingDebugTypes feature), the subprograms end up
having wrong retainedNodes list/scoping relationship.

To tackle this issue, in
llvm#142166, it was proposed
to force-unique all DISubporgrams even if they don't contain odr-uniqued types
(llvm#142166 (comment)).
It should establish one-to-one-to-many relationship between
DISubprograms, abstract DIEs and function clones (from different CUs, in
case of LTO).

To implement that, AsmPrinter should support correct emission of debug info
for DISubprograms attached to multiple functions. This is the goal of
this commit.

Here, LexicalScope's function map is changed to multimap between
DISubprogram and (possible multiple) functions attached to it.
LexicalScope is modified to create an abstract scope for a DISubprogram
having multiple lllvm::Function attachments.
`DwarfCompileUnit::getOrCreateSubprogramDIE` can recognize the case of
DISubprogram attached to multiple Functions, and return abstract DIE
when needed.

CodeViewDebug is adopted as well. UDTs are ensured to be emmited properly in
the cases that are addressed here. Please let me know if more changes
to CodeView needed, as I'm not very familiar with the format.

…o multiple Functions

Depends on:
* llvm#152680
* llvm#162852

In llvm#75385 (and the following
tries), an attempt was made, to support attaching local types to
DILocalScopes, and to store function local types in DISubprogram's
`retainedNodes:` field.

That patch failed to land due to issues arising during LTO process.
If two definition DISubprograms from different compile units
represent, essentially, the same source code function, and have
common local DICompositeType, and if this DICompositeType is uniqued
(due to ODRUniquingDebugTypes feature), the subprograms end up
having wrong retainedNodes list/scoping relationship.

To tackle this issue, in
llvm#142166, it was proposed
to force-unique all DISubporgrams even if they don't contain odr-uniqued types
(llvm#142166 (comment)).
It should establish one-to-one-to-many relationship between
DISubprograms, abstract DIEs and function clones (from different CUs, in
case of LTO).

To implement that, AsmPrinter should support correct emission of debug info
for DISubprograms attached to multiple functions. This is the goal of
this commit.

Here, LexicalScope's function map is changed to multimap between
DISubprogram and (possible multiple) functions attached to it.
LexicalScope is modified to create an abstract scope for a DISubprogram
having multiple lllvm::Function attachments.
`DwarfCompileUnit::getOrCreateSubprogramDIE` can recognize the case of
DISubprogram attached to multiple Functions, and return abstract DIE
when needed.

CodeViewDebug is adopted as well. UDTs are ensured to be emmited properly in
the cases that are addressed here. Please let me know if more changes
to CodeView needed, as I'm not very familiar with the format.

…o multiple Functions

Depends on:
* llvm#152680
* llvm#162852

In llvm#75385 (and the following
tries), an attempt was made, to support attaching local types to
DILocalScopes, and to store function local types in DISubprogram's
`retainedNodes:` field.

That patch failed to land due to issues arising during LTO process.
If two definition DISubprograms from different compile units
represent, essentially, the same source code function, and have
common local DICompositeType, and if this DICompositeType is uniqued
(due to ODRUniquingDebugTypes feature), the subprograms end up
having wrong retainedNodes list/scoping relationship.

To tackle this issue, in
llvm#142166, it was proposed
to force-unique all DISubporgrams even if they don't contain odr-uniqued types
(llvm#142166 (comment)).
It should establish one-to-one-to-many relationship between
DISubprograms, abstract DIEs and function clones (from different CUs, in
case of LTO).

To implement that, AsmPrinter should support correct emission of debug info
for DISubprograms attached to multiple functions. This is the goal of
this commit.

Here, LexicalScope's function map is changed to multimap between
DISubprogram and (possible multiple) functions attached to it.
LexicalScope is modified to create an abstract scope for a DISubprogram
having multiple lllvm::Function attachments.
`DwarfCompileUnit::getOrCreateSubprogramDIE` can recognize the case of
DISubprogram attached to multiple Functions, and return abstract DIE
when needed.

CodeViewDebug is adopted as well. UDTs are ensured to be emmited properly in
the cases that are addressed here. Please let me know if more changes
to CodeView needed, as I'm not very familiar with the format.

…o multiple Functions

Depends on:
* llvm#152680
* llvm#162852

In llvm#75385 (and the following
tries), an attempt was made, to support attaching local types to
DILocalScopes, and to store function local types in DISubprogram's
`retainedNodes:` field.

That patch failed to land due to issues arising during LTO process.
If two definition DISubprograms from different compile units
represent, essentially, the same source code function, and have
common local DICompositeType, and if this DICompositeType is uniqued
(due to ODRUniquingDebugTypes feature), the subprograms end up
having wrong retainedNodes list/scoping relationship.

To tackle this issue, in
llvm#142166, it was proposed
to force-unique all DISubporgrams even if they don't contain odr-uniqued types
(llvm#142166 (comment)).
It should establish one-to-one-to-many relationship between
DISubprograms, abstract DIEs and function clones (from different CUs, in
case of LTO).

To implement that, AsmPrinter should support correct emission of debug info
for DISubprograms attached to multiple functions. This is the goal of
this commit.

Here, LexicalScope's function map is changed to multimap between
DISubprogram and (possible multiple) functions attached to it.
LexicalScope is modified to create an abstract scope for a DISubprogram
having multiple lllvm::Function attachments.
`DwarfCompileUnit::getOrCreateSubprogramDIE` can recognize the case of
DISubprogram attached to multiple Functions, and return abstract DIE
when needed.

CodeViewDebug is adopted as well. UDTs are ensured to be emmited properly in
the cases that are addressed here. Please let me know if more changes
to CodeView needed, as I'm not very familiar with the format.

…exical block scopes (4/7)"

This is an attempt to merge https://reviews.llvm.org/D144006 with LTO
fix.

The last merge attempt was llvm#75385.
The issue with it was investigated in
llvm#75385 (comment).
If the same (in the sense of ODR identifier/ODR uniquing rules) local type
is present in two modules, and these modules are linked together, the type
gets uniqued. A DIType, that happens to be loaded first, survives linking,
and the references on other types with the same ODR identifier from the modules
loaded later are replaced with the references on the DIType loaded first.
Since defintion subprograms, in scope of which these types are located,
are not deduplicated, the linker output may contain multiple
DISubprogram's having the same (uniqued) type in their retainedNodes
lists.
Further compilation of such modules causes crashes.

To tackle that,
(1) previous solution to handle LTO linking with local types in
retainedNodes is removed (cloneLocalTypes() function),
(2) for each loaded distinct (definition) DISubprogram, its retainedNodes
list is scanned after loading, and DITypes with a scope of another subprogram
are removed.

With this approach, clang builds without crashes in FullLTO (which is not
the case for llvm#75385).

Additionally:
- a check is added to Verifier to report about local types located
in a wrong retainedNodes list,
- DIBuilder's methods for type creation are updated, as https://reviews.llvm.org/D144006
has gotten slightly out-of-date.

Commit llvm#75385 is separated from
the new changes to simplify review process.

…exical block scopes (4/7)"

This is an attempt to merge https://reviews.llvm.org/D144006 with LTO
fix.

The last merge attempt was llvm#75385.
The issue with it was investigated in
llvm#75385 (comment).
If the same (in the sense of ODR identifier/ODR uniquing rules) local type
is present in two modules, and these modules are linked together, the type
gets uniqued. A DIType, that happens to be loaded first, survives linking,
and the references on other types with the same ODR identifier from the modules
loaded later are replaced with the references on the DIType loaded first.
Since defintion subprograms, in scope of which these types are located,
are not deduplicated, the linker output may contain multiple
DISubprogram's having the same (uniqued) type in their retainedNodes
lists.
Further compilation of such modules causes crashes.

To tackle that,
(1) previous solution to handle LTO linking with local types in
retainedNodes is removed (cloneLocalTypes() function),
(2) for each loaded distinct (definition) DISubprogram, its retainedNodes
list is scanned after loading, and DITypes with a scope of another subprogram
are removed. If something from a Function corresponding to the
DISubprogram references uniqued type, we rely on cross-CU links.

With this approach, clang builds without crashes in FullLTO (which is not
the case for llvm#75385).

Additionally:
- a check is added to Verifier to report about local types located
in a wrong retainedNodes list,
- DIBuilder's methods for type creation are updated, as https://reviews.llvm.org/D144006
has gotten slightly out-of-date.

Commit llvm#75385 and the new changes
are placed in separate commits to simplify review process.

…exical block scopes (4/7)"

This is an attempt to merge https://reviews.llvm.org/D144006 with LTO
fix.

The last merge attempt was llvm#75385.
The issue with it was investigated in
llvm#75385 (comment).
If the same (in the sense of ODR identifier/ODR uniquing rules) local type
is present in two modules, and these modules are linked together, the type
gets uniqued. A DIType, that happens to be loaded first, survives linking,
and the references on other types with the same ODR identifier from the modules
loaded later are replaced with the references on the DIType loaded first.
Since defintion subprograms, in scope of which these types are located,
are not deduplicated, the linker output may contain multiple
DISubprogram's having the same (uniqued) type in their retainedNodes
lists.
Further compilation of such modules causes crashes.

To tackle that,
* previous solution to handle LTO linking with local types in
retainedNodes is removed (cloneLocalTypes() function),
* for each loaded distinct (definition) DISubprogram, its retainedNodes
list is scanned after loading, and DITypes with a scope of another subprogram
are removed. If something from a Function corresponding to the
DISubprogram references uniqued type, we rely on cross-CU links.

With this approach, clang builds without crashes in FullLTO (which is not
the case for llvm#75385).

Additionally:
* a check is added to Verifier to report about local types located
in a wrong retainedNodes list,
* DIBuilder's methods for type creation are updated, as https://reviews.llvm.org/D144006
has gotten slightly out-of-date.

Commit llvm#75385 and the new changes
are placed in separate commits to simplify review process.

…exical block scopes (4/7)"

This is an attempt to merge https://reviews.llvm.org/D144006 with LTO
fix.

The last merge attempt was llvm#75385.
The issue with it was investigated in
llvm#75385 (comment).
If the same (in the sense of ODR identifier/ODR uniquing rules) local type
is present in two modules, and these modules are linked together, the type
gets uniqued. A DIType, that happens to be loaded first, survives linking,
and the references on other types with the same ODR identifier from the modules
loaded later are replaced with the references on the DIType loaded first.
Since defintion subprograms, in scope of which these types are located,
are not deduplicated, the linker output may contain multiple
DISubprogram's having the same (uniqued) type in their retainedNodes
lists.
Further compilation of such modules causes crashes.

To tackle that,
* previous solution to handle LTO linking with local types in
retainedNodes is removed (cloneLocalTypes() function),
* for each loaded distinct (definition) DISubprogram, its retainedNodes
list is scanned after loading, and DITypes with a scope of another subprogram
are removed. If something from a Function corresponding to the
DISubprogram references uniqued type, we rely on cross-CU links.

With this approach, clang builds without crashes in FullLTO (which is not
the case for llvm#75385).

Additionally:
* a check is added to Verifier to report about local types located
in a wrong retainedNodes list,
* DIBuilder's methods for type creation are updated, as https://reviews.llvm.org/D144006
has gotten slightly out-of-date.

Commit llvm#75385 and the new changes
are placed in separate commits to simplify review process.

…exical block scopes (4/7)"

This is an attempt to merge https://reviews.llvm.org/D144006 with LTO
fix.

The last merge attempt was llvm#75385.
The issue with it was investigated in
llvm#75385 (comment).
If the same (in the sense of ODR identifier/ODR uniquing rules) local type
is present in two modules, and these modules are linked together, the type
gets uniqued. A DIType, that happens to be loaded first, survives linking,
and the references on other types with the same ODR identifier from the modules
loaded later are replaced with the references on the DIType loaded first.
Since defintion subprograms, in scope of which these types are located,
are not deduplicated, the linker output may contain multiple
DISubprogram's having the same (uniqued) type in their retainedNodes
lists.
Further compilation of such modules causes crashes.

To tackle that,
* previous solution to handle LTO linking with local types in
retainedNodes is removed (cloneLocalTypes() function),
* for each loaded distinct (definition) DISubprogram, its retainedNodes
list is scanned after loading, and DITypes with a scope of another subprogram
are removed. If something from a Function corresponding to the
DISubprogram references uniqued type, we rely on cross-CU links.

With this approach, clang builds without crashes in FullLTO (which is not
the case for llvm#75385).

Additionally:
* a check is added to Verifier to report about local types located
in a wrong retainedNodes list,
* DIBuilder's methods for type creation are updated, as https://reviews.llvm.org/D144006
has gotten slightly out-of-date.

Commit llvm#75385 and the new changes
are placed in separate commits to simplify review process.

These checks ensure that retained nodes of a DISubprogram belong
to the subprogram.

This was helpful to find issues with https://reviews.llvm.org/D144004,
llvm#75385,
llvm#165032.

Also, interface for accessing DISubprogram's retained nodes is slightly
refactored. `DISubprogram::visitRetainedNodes` and
`DISubprogram::forEachRetainedNode` are added to avoid repeating
checks like
```
if (const auto *LV = dyn_cast<DILocalVariable>(N))
  ...
else if (const auto *L = dyn_cast<DILabel>(N))
  ...
else if (const auto *IE = dyn_cast<DIImportedEntity>(N))
  ...
```

Tests with wrongly scoped retained nodes are fixed.

…exical block scopes (4/7)"

This is an attempt to merge https://reviews.llvm.org/D144006 with LTO
fix.

The last merge attempt was llvm#75385.
The issue with it was investigated in
llvm#75385 (comment).
If the same (in the sense of ODR identifier/ODR uniquing rules) local type
is present in two modules, and these modules are linked together, the type
gets uniqued. A DIType, that happens to be loaded first, survives linking,
and the references on other types with the same ODR identifier from the modules
loaded later are replaced with the references on the DIType loaded first.
Since defintion subprograms, in scope of which these types are located,
are not deduplicated, the linker output may contain multiple
DISubprogram's having the same (uniqued) type in their retainedNodes
lists.
Further compilation of such modules causes crashes.

To tackle that,
* previous solution to handle LTO linking with local types in
retainedNodes is removed (cloneLocalTypes() function),
* for each loaded distinct (definition) DISubprogram, its retainedNodes
list is scanned after loading, and DITypes with a scope of another subprogram
are removed. If something from a Function corresponding to the
DISubprogram references uniqued type, we rely on cross-CU links.

With this approach, clang builds without crashes in FullLTO (which is not
the case for llvm#75385).

Additionally:
* a check is added to Verifier to report about local types located
in a wrong retainedNodes list,
* DIBuilder's methods for type creation are updated, as https://reviews.llvm.org/D144006
has gotten slightly out-of-date.

Commit llvm#75385 and the new changes
are placed in separate commits to simplify review process.

…exical block scopes (4/7)"

This is an attempt to merge https://reviews.llvm.org/D144006 with LTO
fix.

The last merge attempt was llvm#75385.
The issue with it was investigated in
llvm#75385 (comment).
If the same (in the sense of ODR identifier/ODR uniquing rules) local type
is present in two modules, and these modules are linked together, the type
gets uniqued. A DIType, that happens to be loaded first, survives linking,
and the references on other types with the same ODR identifier from the modules
loaded later are replaced with the references on the DIType loaded first.
Since defintion subprograms, in scope of which these types are located,
are not deduplicated, the linker output may contain multiple
DISubprogram's having the same (uniqued) type in their retainedNodes
lists.
Further compilation of such modules causes crashes.

To tackle that,
* previous solution to handle LTO linking with local types in
retainedNodes is removed (cloneLocalTypes() function),
* for each loaded distinct (definition) DISubprogram, its retainedNodes
list is scanned after loading, and DITypes with a scope of another subprogram
are removed. If something from a Function corresponding to the
DISubprogram references uniqued type, we rely on cross-CU links.

With this approach, clang builds without crashes in FullLTO (which is not
the case for llvm#75385).

Additionally:
* a check is added to Verifier to report about local types located
in a wrong retainedNodes list,
* DIBuilder's methods for type creation are updated, as https://reviews.llvm.org/D144006
has gotten slightly out-of-date.

Commit llvm#75385 and the new changes
are placed in separate commits to simplify review process.

…exical block scopes (4/7)"

This is an attempt to merge https://reviews.llvm.org/D144006 with LTO
fix.

The last merge attempt was llvm#75385.
The issue with it was investigated in
llvm#75385 (comment).
If the same (in the sense of ODR identifier/ODR uniquing rules) local type
is present in two modules, and these modules are linked together, the type
gets uniqued. A DIType, that happens to be loaded first, survives linking,
and the references on other types with the same ODR identifier from the modules
loaded later are replaced with the references on the DIType loaded first.
Since defintion subprograms, in scope of which these types are located,
are not deduplicated, the linker output may contain multiple
DISubprogram's having the same (uniqued) type in their retainedNodes
lists.
Further compilation of such modules causes crashes.

To tackle that,
* previous solution to handle LTO linking with local types in
retainedNodes is removed (cloneLocalTypes() function),
* for each loaded distinct (definition) DISubprogram, its retainedNodes
list is scanned after loading, and DITypes with a scope of another subprogram
are removed. If something from a Function corresponding to the
DISubprogram references uniqued type, we rely on cross-CU links.

With this approach, clang builds without crashes in FullLTO (which is not
the case for llvm#75385).

Additionally:
* a check is added to Verifier to report about local types located
in a wrong retainedNodes list,
* DIBuilder's methods for type creation are updated, as https://reviews.llvm.org/D144006
has gotten slightly out-of-date.

Commit llvm#75385 and the new changes
are placed in separate commits to simplify review process.

…exical block scopes (4/7)"

This is an attempt to merge https://reviews.llvm.org/D144006 with LTO
fix.

The last merge attempt was llvm#75385.
The issue with it was investigated in
llvm#75385 (comment).
If the same (in the sense of ODR identifier/ODR uniquing rules) local type
is present in two modules, and these modules are linked together, the type
gets uniqued. A DIType, that happens to be loaded first, survives linking,
and the references on other types with the same ODR identifier from the modules
loaded later are replaced with the references on the DIType loaded first.
Since defintion subprograms, in scope of which these types are located,
are not deduplicated, the linker output may contain multiple
DISubprogram's having the same (uniqued) type in their retainedNodes
lists.
Further compilation of such modules causes crashes.

To tackle that,
* previous solution to handle LTO linking with local types in
retainedNodes is removed (cloneLocalTypes() function),
* for each loaded distinct (definition) DISubprogram, its retainedNodes
list is scanned after loading, and DITypes with a scope of another subprogram
are removed. If something from a Function corresponding to the
DISubprogram references uniqued type, we rely on cross-CU links.

With this approach, clang builds without crashes in FullLTO (which is not
the case for llvm#75385).

Additionally:
* a check is added to Verifier to report about local types located
in a wrong retainedNodes list,
* DIBuilder's methods for type creation are updated, as https://reviews.llvm.org/D144006
has gotten slightly out-of-date.

Commit llvm#75385 and the new changes
are placed in separate commits to simplify review process.

…exical block scopes (4/7)"

This is an attempt to merge https://reviews.llvm.org/D144006 with LTO
fix.

The last merge attempt was llvm#75385.
The issue with it was investigated in
llvm#75385 (comment).
If the same (in the sense of ODR identifier/ODR uniquing rules) local type
is present in two modules, and these modules are linked together, the type
gets uniqued. A DIType, that happens to be loaded first, survives linking,
and the references on other types with the same ODR identifier from the modules
loaded later are replaced with the references on the DIType loaded first.
Since defintion subprograms, in scope of which these types are located,
are not deduplicated, the linker output may contain multiple
DISubprogram's having the same (uniqued) type in their retainedNodes
lists.
Further compilation of such modules causes crashes.

To tackle that,
* previous solution to handle LTO linking with local types in
retainedNodes is removed (cloneLocalTypes() function),
* for each loaded distinct (definition) DISubprogram, its retainedNodes
list is scanned after loading, and DITypes with a scope of another subprogram
are removed. If something from a Function corresponding to the
DISubprogram references uniqued type, we rely on cross-CU links.

With this approach, clang builds without crashes in FullLTO (which is not
the case for llvm#75385).

Additionally:
* a check is added to Verifier to report about local types located
in a wrong retainedNodes list,
* DIBuilder's methods for type creation are updated, as https://reviews.llvm.org/D144006
has gotten slightly out-of-date.

Commit llvm#75385 and the new changes
are placed in separate commits to simplify review process.

…exical block scopes (4/7)"

This is an attempt to merge https://reviews.llvm.org/D144006 with LTO
fix.

The last merge attempt was llvm#75385.
The issue with it was investigated in
llvm#75385 (comment).
If the same (in the sense of ODR identifier/ODR uniquing rules) local type
is present in two modules, and these modules are linked together, the type
gets uniqued. A DIType, that happens to be loaded first, survives linking,
and the references on other types with the same ODR identifier from the modules
loaded later are replaced with the references on the DIType loaded first.
Since defintion subprograms, in scope of which these types are located,
are not deduplicated, the linker output may contain multiple
DISubprogram's having the same (uniqued) type in their retainedNodes
lists.
Further compilation of such modules causes crashes.

To tackle that,
* previous solution to handle LTO linking with local types in
retainedNodes is removed (cloneLocalTypes() function),
* for each loaded distinct (definition) DISubprogram, its retainedNodes
list is scanned after loading, and DITypes with a scope of another subprogram
are removed. If something from a Function corresponding to the
DISubprogram references uniqued type, we rely on cross-CU links.

With this approach, clang builds without crashes in FullLTO (which is not
the case for llvm#75385).

Additionally:
* a check is added to Verifier to report about local types located
in a wrong retainedNodes list,
* DIBuilder's methods for type creation are updated, as https://reviews.llvm.org/D144006
has gotten slightly out-of-date.

Commit llvm#75385 and the new changes
are placed in separate commits to simplify review process.

…exical block scopes (4/7)"

This is an attempt to merge https://reviews.llvm.org/D144006 with LTO
fix.

The last merge attempt was llvm#75385.
The issue with it was investigated in
llvm#75385 (comment).
If the same (in the sense of ODR identifier/ODR uniquing rules) local type
is present in two modules, and these modules are linked together, the type
gets uniqued. A DIType, that happens to be loaded first, survives linking,
and the references on other types with the same ODR identifier from the modules
loaded later are replaced with the references on the DIType loaded first.
Since defintion subprograms, in scope of which these types are located,
are not deduplicated, the linker output may contain multiple
DISubprogram's having the same (uniqued) type in their retainedNodes
lists.
Further compilation of such modules causes crashes.

To tackle that,
* previous solution to handle LTO linking with local types in
retainedNodes is removed (cloneLocalTypes() function),
* for each loaded distinct (definition) DISubprogram, its retainedNodes
list is scanned after loading, and DITypes with a scope of another subprogram
are removed. If something from a Function corresponding to the
DISubprogram references uniqued type, we rely on cross-CU links.

With this approach, clang builds without crashes in FullLTO (which is not
the case for llvm#75385).

Additionally:
* a check is added to Verifier to report about local types located
in a wrong retainedNodes list,
* DIBuilder's methods for type creation are updated, as https://reviews.llvm.org/D144006
has gotten slightly out-of-date.

Commit llvm#75385 and the new changes
are placed in separate commits to simplify review process.

…exical block scopes (4/7)" (#165032)

This is an attempt to merge https://reviews.llvm.org/D144006 with LTO
fix.

The last merge attempt was
#75385.
The issue with it was investigated in
#75385 (comment).
The problem happens when 
1. Several modules are being linked.
2. There are several DISubprograms that initially belong to different
modules but represent the same source code function (for example, a
function included from the same source code file).
3. Some of such DISubprograms survive IR linking. It may happen if one
of them is inlined somewhere or if the functions that have these
DISubprograms attached have internal linkage.
4. Each of these DISubprograms has a local type that corresponds to the
same source code type. These types are initially from different modules,
but have the same ODR identifier.

If the same (in the sense of ODR identifier/ODR uniquing rules) local
type is present in two modules, and these modules are linked together,
the type gets uniqued. A DIType, that happens to be loaded first,
survives linking, and the references on other types with the same ODR
identifier from the modules loaded later are replaced with the
references on the DIType loaded first. Since defintion subprograms, in
scope of which these types are located, are not deduplicated, the linker
output may contain multiple DISubprogram's having the same (uniqued)
type in their retainedNodes lists.
Further compilation of such modules causes crashes.

To tackle that,
* previous solution to handle LTO linking with local types in
retainedNodes is removed (cloneLocalTypes() function),
* for each loaded distinct (definition) DISubprogram, its retainedNodes
list is scanned after loading, and DITypes with a scope of another
subprogram are removed. If something from a Function corresponding to
the DISubprogram references uniqued type, we rely on cross-CU links.

Additionally:
* a check is added to Verifier to report about local types located in a
wrong retainedNodes list,

Original commit message follows.
---------

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 <[email protected]>
Co-authored-by: Jeremy Morse <[email protected]>

… types in lexical block scopes (4/7)" (#165032)

This is an attempt to merge https://reviews.llvm.org/D144006 with LTO
fix.

The last merge attempt was
llvm/llvm-project#75385.
The issue with it was investigated in
llvm/llvm-project#75385 (comment).
The problem happens when
1. Several modules are being linked.
2. There are several DISubprograms that initially belong to different
modules but represent the same source code function (for example, a
function included from the same source code file).
3. Some of such DISubprograms survive IR linking. It may happen if one
of them is inlined somewhere or if the functions that have these
DISubprograms attached have internal linkage.
4. Each of these DISubprograms has a local type that corresponds to the
same source code type. These types are initially from different modules,
but have the same ODR identifier.

If the same (in the sense of ODR identifier/ODR uniquing rules) local
type is present in two modules, and these modules are linked together,
the type gets uniqued. A DIType, that happens to be loaded first,
survives linking, and the references on other types with the same ODR
identifier from the modules loaded later are replaced with the
references on the DIType loaded first. Since defintion subprograms, in
scope of which these types are located, are not deduplicated, the linker
output may contain multiple DISubprogram's having the same (uniqued)
type in their retainedNodes lists.
Further compilation of such modules causes crashes.

To tackle that,
* previous solution to handle LTO linking with local types in
retainedNodes is removed (cloneLocalTypes() function),
* for each loaded distinct (definition) DISubprogram, its retainedNodes
list is scanned after loading, and DITypes with a scope of another
subprogram are removed. If something from a Function corresponding to
the DISubprogram references uniqued type, we rely on cross-CU links.

Additionally:
* a check is added to Verifier to report about local types located in a
wrong retainedNodes list,

Original commit message follows.
---------

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 <[email protected]>
Co-authored-by: Jeremy Morse <[email protected]>

…exical block scopes (4/7)" (llvm#165032)

This is an attempt to merge https://reviews.llvm.org/D144006 with LTO
fix.

The last merge attempt was
llvm#75385.
The issue with it was investigated in
llvm#75385 (comment).
The problem happens when 
1. Several modules are being linked.
2. There are several DISubprograms that initially belong to different
modules but represent the same source code function (for example, a
function included from the same source code file).
3. Some of such DISubprograms survive IR linking. It may happen if one
of them is inlined somewhere or if the functions that have these
DISubprograms attached have internal linkage.
4. Each of these DISubprograms has a local type that corresponds to the
same source code type. These types are initially from different modules,
but have the same ODR identifier.

If the same (in the sense of ODR identifier/ODR uniquing rules) local
type is present in two modules, and these modules are linked together,
the type gets uniqued. A DIType, that happens to be loaded first,
survives linking, and the references on other types with the same ODR
identifier from the modules loaded later are replaced with the
references on the DIType loaded first. Since defintion subprograms, in
scope of which these types are located, are not deduplicated, the linker
output may contain multiple DISubprogram's having the same (uniqued)
type in their retainedNodes lists.
Further compilation of such modules causes crashes.

To tackle that,
* previous solution to handle LTO linking with local types in
retainedNodes is removed (cloneLocalTypes() function),
* for each loaded distinct (definition) DISubprogram, its retainedNodes
list is scanned after loading, and DITypes with a scope of another
subprogram are removed. If something from a Function corresponding to
the DISubprogram references uniqued type, we rely on cross-CU links.

Additionally:
* a check is added to Verifier to report about local types located in a
wrong retainedNodes list,

Original commit message follows.
---------

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 <[email protected]>
Co-authored-by: Jeremy Morse <[email protected]>