Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
2010-11-04 15:01:38 +00:00
|
|
|
//===--- DIBuilder.cpp - Debug Information Builder ------------------------===//
|
|
|
|
//
|
2019-01-19 08:50:56 +00:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
2010-11-04 15:01:38 +00:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file implements the DIBuilder.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-03-06 00:22:06 +00:00
|
|
|
#include "llvm/IR/DIBuilder.h"
|
2017-06-06 11:49:48 +00:00
|
|
|
#include "LLVMContextImpl.h"
|
2023-06-17 13:18:23 +01:00
|
|
|
#include "llvm/ADT/APInt.h"
|
|
|
|
#include "llvm/ADT/APSInt.h"
|
2017-06-07 03:48:56 +00:00
|
|
|
#include "llvm/BinaryFormat/Dwarf.h"
|
2013-01-02 11:36:10 +00:00
|
|
|
#include "llvm/IR/Constants.h"
|
2014-03-06 00:46:21 +00:00
|
|
|
#include "llvm/IR/DebugInfo.h"
|
2019-11-14 15:15:48 -08:00
|
|
|
#include "llvm/IR/IRBuilder.h"
|
2013-01-02 11:36:10 +00:00
|
|
|
#include "llvm/IR/Module.h"
|
2022-12-03 16:01:15 -06:00
|
|
|
#include <optional>
|
Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
2010-11-04 15:01:38 +00:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
using namespace llvm::dwarf;
|
|
|
|
|
2018-01-19 21:21:49 +00:00
|
|
|
DIBuilder::DIBuilder(Module &m, bool AllowUnresolvedNodes, DICompileUnit *CU)
|
2021-11-11 13:39:50 -08:00
|
|
|
: M(m), VMContext(M.getContext()), CUNode(CU), DeclareFn(nullptr),
|
2023-02-25 22:44:04 +00:00
|
|
|
ValueFn(nullptr), LabelFn(nullptr), AssignFn(nullptr),
|
2021-11-29 19:43:25 -08:00
|
|
|
AllowUnresolvedNodes(AllowUnresolvedNodes) {
|
|
|
|
if (CUNode) {
|
|
|
|
if (const auto &ETs = CUNode->getEnumTypes())
|
2024-01-16 16:56:24 -08:00
|
|
|
AllEnumTypes.assign(ETs.begin(), ETs.end());
|
2021-11-29 19:43:25 -08:00
|
|
|
if (const auto &RTs = CUNode->getRetainedTypes())
|
|
|
|
AllRetainTypes.assign(RTs.begin(), RTs.end());
|
|
|
|
if (const auto &GVs = CUNode->getGlobalVariables())
|
|
|
|
AllGVs.assign(GVs.begin(), GVs.end());
|
|
|
|
if (const auto &IMs = CUNode->getImportedEntities())
|
2023-06-15 12:22:16 +02:00
|
|
|
ImportedModules.assign(IMs.begin(), IMs.end());
|
2021-11-29 19:43:25 -08:00
|
|
|
if (const auto &MNs = CUNode->getMacros())
|
|
|
|
AllMacrosPerParent.insert({nullptr, {MNs.begin(), MNs.end()}});
|
|
|
|
}
|
|
|
|
}
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-09 18:38:53 +00:00
|
|
|
|
|
|
|
void DIBuilder::trackIfUnresolved(MDNode *N) {
|
2015-01-19 19:09:14 +00:00
|
|
|
if (!N)
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-09 18:38:53 +00:00
|
|
|
return;
|
2015-01-19 19:09:14 +00:00
|
|
|
if (N->isResolved())
|
|
|
|
return;
|
|
|
|
|
|
|
|
assert(AllowUnresolvedNodes && "Cannot handle unresolved nodes");
|
|
|
|
UnresolvedNodes.emplace_back(N);
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-09 18:38:53 +00:00
|
|
|
}
|
Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
2010-11-04 15:01:38 +00:00
|
|
|
|
2017-06-01 20:42:44 +00:00
|
|
|
void DIBuilder::finalizeSubprogram(DISubprogram *SP) {
|
2023-06-12 16:01:18 +02:00
|
|
|
auto PN = SubprogramTrackedNodes.find(SP);
|
|
|
|
if (PN != SubprogramTrackedNodes.end())
|
|
|
|
SP->replaceRetainedNodes(
|
|
|
|
MDTuple::get(VMContext, SmallVector<Metadata *, 16>(PN->second.begin(),
|
|
|
|
PN->second.end())));
|
2017-06-01 20:42:44 +00:00
|
|
|
}
|
|
|
|
|
2011-08-15 23:00:00 +00:00
|
|
|
void DIBuilder::finalize() {
|
2015-07-06 16:22:12 +00:00
|
|
|
if (!CUNode) {
|
|
|
|
assert(!AllowUnresolvedNodes &&
|
|
|
|
"creating type nodes without a CU is not supported");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2024-01-16 16:56:24 -08:00
|
|
|
if (!AllEnumTypes.empty())
|
|
|
|
CUNode->replaceEnumTypes(MDTuple::get(
|
|
|
|
VMContext, SmallVector<Metadata *, 16>(AllEnumTypes.begin(),
|
|
|
|
AllEnumTypes.end())));
|
2015-07-06 16:22:12 +00:00
|
|
|
|
|
|
|
SmallVector<Metadata *, 16> RetainValues;
|
|
|
|
// Declarations and definitions of the same type may be retained. Some
|
|
|
|
// clients RAUW these pairs, leaving duplicates in the retained types
|
|
|
|
// list. Use a set to remove the duplicates while we transform the
|
|
|
|
// TrackingVHs back into Values.
|
|
|
|
SmallPtrSet<Metadata *, 16> RetainSet;
|
2024-07-03 12:53:06 -07:00
|
|
|
for (const TrackingMDNodeRef &N : AllRetainTypes)
|
|
|
|
if (RetainSet.insert(N).second)
|
|
|
|
RetainValues.push_back(N);
|
2015-07-06 16:36:02 +00:00
|
|
|
|
|
|
|
if (!RetainValues.empty())
|
|
|
|
CUNode->replaceRetainedTypes(MDTuple::get(VMContext, RetainValues));
|
2015-07-06 16:22:12 +00:00
|
|
|
|
2023-04-04 07:42:25 -04:00
|
|
|
for (auto *SP : AllSubprograms)
|
2017-06-01 20:42:44 +00:00
|
|
|
finalizeSubprogram(SP);
|
2016-04-15 15:57:41 +00:00
|
|
|
for (auto *N : RetainValues)
|
|
|
|
if (auto *SP = dyn_cast<DISubprogram>(N))
|
2017-06-01 20:42:44 +00:00
|
|
|
finalizeSubprogram(SP);
|
2011-08-16 22:09:43 +00:00
|
|
|
|
2015-07-06 16:36:02 +00:00
|
|
|
if (!AllGVs.empty())
|
|
|
|
CUNode->replaceGlobalVariables(MDTuple::get(VMContext, AllGVs));
|
2013-04-22 06:12:31 +00:00
|
|
|
|
2023-06-15 12:22:16 +02:00
|
|
|
if (!ImportedModules.empty())
|
2015-07-06 16:36:02 +00:00
|
|
|
CUNode->replaceImportedEntities(MDTuple::get(
|
2023-06-15 12:22:16 +02:00
|
|
|
VMContext, SmallVector<Metadata *, 16>(ImportedModules.begin(),
|
|
|
|
ImportedModules.end())));
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-09 18:38:53 +00:00
|
|
|
|
2017-01-12 15:49:46 +00:00
|
|
|
for (const auto &I : AllMacrosPerParent) {
|
|
|
|
// DIMacroNode's with nullptr parent are DICompileUnit direct children.
|
|
|
|
if (!I.first) {
|
|
|
|
CUNode->replaceMacros(MDTuple::get(VMContext, I.second.getArrayRef()));
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
// Otherwise, it must be a temporary DIMacroFile that need to be resolved.
|
|
|
|
auto *TMF = cast<DIMacroFile>(I.first);
|
|
|
|
auto *MF = DIMacroFile::get(VMContext, dwarf::DW_MACINFO_start_file,
|
|
|
|
TMF->getLine(), TMF->getFile(),
|
|
|
|
getOrCreateMacroArray(I.second.getArrayRef()));
|
|
|
|
replaceTemporary(llvm::TempDIMacroNode(TMF), MF);
|
|
|
|
}
|
|
|
|
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-09 18:38:53 +00:00
|
|
|
// Now that all temp nodes have been replaced or deleted, resolve remaining
|
|
|
|
// cycles.
|
|
|
|
for (const auto &N : UnresolvedNodes)
|
2015-01-19 23:13:14 +00:00
|
|
|
if (N && !N->isResolved())
|
|
|
|
N->resolveCycles();
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-09 18:38:53 +00:00
|
|
|
UnresolvedNodes.clear();
|
|
|
|
|
|
|
|
// Can't handle unresolved nodes anymore.
|
|
|
|
AllowUnresolvedNodes = false;
|
2011-08-16 22:09:43 +00:00
|
|
|
}
|
|
|
|
|
2014-10-01 21:32:15 +00:00
|
|
|
/// If N is compile unit return NULL otherwise return N.
|
2015-04-29 16:38:44 +00:00
|
|
|
static DIScope *getNonCompileUnitScope(DIScope *N) {
|
|
|
|
if (!N || isa<DICompileUnit>(N))
|
2014-04-09 06:08:46 +00:00
|
|
|
return nullptr;
|
2015-04-29 16:38:44 +00:00
|
|
|
return cast<DIScope>(N);
|
2011-08-15 23:00:00 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DICompileUnit *DIBuilder::createCompileUnit(
|
2016-12-14 20:24:54 +00:00
|
|
|
unsigned Lang, DIFile *File, StringRef Producer, bool isOptimized,
|
|
|
|
StringRef Flags, unsigned RunTimeVer, StringRef SplitName,
|
2016-08-24 18:29:49 +00:00
|
|
|
DICompileUnit::DebugEmissionKind Kind, uint64_t DWOId,
|
2018-08-16 21:29:55 +00:00
|
|
|
bool SplitDebugInlining, bool DebugInfoForProfiling,
|
2020-01-14 13:37:04 -08:00
|
|
|
DICompileUnit::DebugNameTableKind NameTableKind, bool RangesBaseAddress,
|
2020-03-04 14:12:54 -08:00
|
|
|
StringRef SysRoot, StringRef SDK) {
|
2014-02-27 01:24:56 +00:00
|
|
|
|
2024-11-22 13:49:42 -08:00
|
|
|
assert(((Lang <= dwarf::DW_LANG_Metal && Lang >= dwarf::DW_LANG_C89) ||
|
2012-01-10 18:18:52 +00:00
|
|
|
(Lang <= dwarf::DW_LANG_hi_user && Lang >= dwarf::DW_LANG_lo_user)) &&
|
|
|
|
"Invalid Language tag");
|
2011-08-16 22:09:43 +00:00
|
|
|
|
2015-07-02 22:32:52 +00:00
|
|
|
assert(!CUNode && "Can only make one compile unit per DIBuilder instance");
|
|
|
|
CUNode = DICompileUnit::getDistinct(
|
2016-12-14 20:24:54 +00:00
|
|
|
VMContext, Lang, File, Producer, isOptimized, Flags, RunTimeVer,
|
|
|
|
SplitName, Kind, nullptr, nullptr, nullptr, nullptr, nullptr, DWOId,
|
2018-11-13 20:08:10 +00:00
|
|
|
SplitDebugInlining, DebugInfoForProfiling, NameTableKind,
|
2020-03-04 14:12:54 -08:00
|
|
|
RangesBaseAddress, SysRoot, SDK);
|
2011-05-03 16:18:28 +00:00
|
|
|
|
|
|
|
// Create a named metadata so that it is easier to find cu in a module.
|
2016-04-08 22:43:03 +00:00
|
|
|
NamedMDNode *NMD = M.getOrInsertNamedMetadata("llvm.dbg.cu");
|
|
|
|
NMD->addOperand(CUNode);
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-09 18:38:53 +00:00
|
|
|
trackIfUnresolved(CUNode);
|
2015-04-06 23:18:49 +00:00
|
|
|
return CUNode;
|
Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
2010-11-04 15:01:38 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
static DIImportedEntity *
|
|
|
|
createImportedModule(LLVMContext &C, dwarf::Tag Tag, DIScope *Context,
|
2017-07-19 00:09:54 +00:00
|
|
|
Metadata *NS, DIFile *File, unsigned Line, StringRef Name,
|
2021-09-07 11:25:44 +05:30
|
|
|
DINodeArray Elements,
|
2023-06-15 12:22:16 +02:00
|
|
|
SmallVectorImpl<TrackingMDNodeRef> &ImportedModules) {
|
2017-07-19 00:09:54 +00:00
|
|
|
if (Line)
|
|
|
|
assert(File && "Source location has line number but no file");
|
2016-03-13 11:11:39 +00:00
|
|
|
unsigned EntitiesCount = C.pImpl->DIImportedEntitys.size();
|
2019-05-07 02:06:37 +00:00
|
|
|
auto *M = DIImportedEntity::get(C, Tag, Context, cast_or_null<DINode>(NS),
|
2021-09-07 11:25:44 +05:30
|
|
|
File, Line, Name, Elements);
|
2016-03-13 11:11:39 +00:00
|
|
|
if (EntitiesCount < C.pImpl->DIImportedEntitys.size())
|
|
|
|
// A new Imported Entity was just added to the context.
|
|
|
|
// Add it to the Imported Modules list.
|
2023-06-15 12:22:16 +02:00
|
|
|
ImportedModules.emplace_back(M);
|
2013-05-07 21:35:53 +00:00
|
|
|
return M;
|
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DIImportedEntity *DIBuilder::createImportedModule(DIScope *Context,
|
2017-07-19 00:09:54 +00:00
|
|
|
DINamespace *NS, DIFile *File,
|
2021-09-07 11:25:44 +05:30
|
|
|
unsigned Line,
|
|
|
|
DINodeArray Elements) {
|
2014-04-06 06:29:01 +00:00
|
|
|
return ::createImportedModule(VMContext, dwarf::DW_TAG_imported_module,
|
2021-09-07 11:25:44 +05:30
|
|
|
Context, NS, File, Line, StringRef(), Elements,
|
2023-06-15 12:22:16 +02:00
|
|
|
getImportTrackingVector(Context));
|
2013-05-20 22:50:35 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DIImportedEntity *DIBuilder::createImportedModule(DIScope *Context,
|
|
|
|
DIImportedEntity *NS,
|
2021-09-07 11:25:44 +05:30
|
|
|
DIFile *File, unsigned Line,
|
|
|
|
DINodeArray Elements) {
|
2014-04-06 06:29:01 +00:00
|
|
|
return ::createImportedModule(VMContext, dwarf::DW_TAG_imported_module,
|
2021-09-07 11:25:44 +05:30
|
|
|
Context, NS, File, Line, StringRef(), Elements,
|
2023-06-15 12:22:16 +02:00
|
|
|
getImportTrackingVector(Context));
|
2013-05-20 22:50:35 +00:00
|
|
|
}
|
|
|
|
|
2015-06-29 23:03:47 +00:00
|
|
|
DIImportedEntity *DIBuilder::createImportedModule(DIScope *Context, DIModule *M,
|
2021-09-07 11:25:44 +05:30
|
|
|
DIFile *File, unsigned Line,
|
|
|
|
DINodeArray Elements) {
|
2015-06-29 23:03:47 +00:00
|
|
|
return ::createImportedModule(VMContext, dwarf::DW_TAG_imported_module,
|
2021-09-07 11:25:44 +05:30
|
|
|
Context, M, File, Line, StringRef(), Elements,
|
2023-06-15 12:22:16 +02:00
|
|
|
getImportTrackingVector(Context));
|
2015-06-29 23:03:47 +00:00
|
|
|
}
|
|
|
|
|
2021-09-07 11:25:44 +05:30
|
|
|
DIImportedEntity *
|
|
|
|
DIBuilder::createImportedDeclaration(DIScope *Context, DINode *Decl,
|
|
|
|
DIFile *File, unsigned Line,
|
|
|
|
StringRef Name, DINodeArray Elements) {
|
2014-11-06 17:46:55 +00:00
|
|
|
// Make sure to use the unique identifier based metadata reference for
|
|
|
|
// types that have one.
|
2014-04-06 06:29:01 +00:00
|
|
|
return ::createImportedModule(VMContext, dwarf::DW_TAG_imported_declaration,
|
2021-09-07 11:25:44 +05:30
|
|
|
Context, Decl, File, Line, Name, Elements,
|
2023-06-15 12:22:16 +02:00
|
|
|
getImportTrackingVector(Context));
|
2013-04-22 06:12:31 +00:00
|
|
|
}
|
|
|
|
|
2016-12-25 10:12:09 +00:00
|
|
|
DIFile *DIBuilder::createFile(StringRef Filename, StringRef Directory,
|
2022-12-03 16:01:15 -06:00
|
|
|
std::optional<DIFile::ChecksumInfo<StringRef>> CS,
|
|
|
|
std::optional<StringRef> Source) {
|
2018-02-23 23:01:06 +00:00
|
|
|
return DIFile::get(VMContext, Filename, Directory, CS, Source);
|
Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
2010-11-04 15:01:38 +00:00
|
|
|
}
|
|
|
|
|
2017-01-12 15:49:46 +00:00
|
|
|
DIMacro *DIBuilder::createMacro(DIMacroFile *Parent, unsigned LineNumber,
|
|
|
|
unsigned MacroType, StringRef Name,
|
|
|
|
StringRef Value) {
|
|
|
|
assert(!Name.empty() && "Unable to create macro without name");
|
|
|
|
assert((MacroType == dwarf::DW_MACINFO_undef ||
|
|
|
|
MacroType == dwarf::DW_MACINFO_define) &&
|
|
|
|
"Unexpected macro type");
|
|
|
|
auto *M = DIMacro::get(VMContext, MacroType, LineNumber, Name, Value);
|
|
|
|
AllMacrosPerParent[Parent].insert(M);
|
|
|
|
return M;
|
|
|
|
}
|
|
|
|
|
|
|
|
DIMacroFile *DIBuilder::createTempMacroFile(DIMacroFile *Parent,
|
|
|
|
unsigned LineNumber, DIFile *File) {
|
|
|
|
auto *MF = DIMacroFile::getTemporary(VMContext, dwarf::DW_MACINFO_start_file,
|
|
|
|
LineNumber, File, DIMacroNodeArray())
|
|
|
|
.release();
|
|
|
|
AllMacrosPerParent[Parent].insert(MF);
|
|
|
|
// Add the new temporary DIMacroFile to the macro per parent map as a parent.
|
|
|
|
// This is needed to assure DIMacroFile with no children to have an entry in
|
|
|
|
// the map. Otherwise, it will not be resolved in DIBuilder::finalize().
|
|
|
|
AllMacrosPerParent.insert({MF, {}});
|
|
|
|
return MF;
|
|
|
|
}
|
|
|
|
|
2021-07-02 00:26:17 +02:00
|
|
|
DIEnumerator *DIBuilder::createEnumerator(StringRef Name, uint64_t Val,
|
2018-02-12 16:10:09 +00:00
|
|
|
bool IsUnsigned) {
|
2011-09-12 18:26:08 +00:00
|
|
|
assert(!Name.empty() && "Unable to create enumerator without name");
|
2020-04-18 11:31:38 -07:00
|
|
|
return DIEnumerator::get(VMContext, APInt(64, Val, !IsUnsigned), IsUnsigned,
|
|
|
|
Name);
|
Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
2010-11-04 15:01:38 +00:00
|
|
|
}
|
|
|
|
|
2021-09-25 11:58:06 +01:00
|
|
|
DIEnumerator *DIBuilder::createEnumerator(StringRef Name, const APSInt &Value) {
|
2021-07-22 12:38:57 -07:00
|
|
|
assert(!Name.empty() && "Unable to create enumerator without name");
|
|
|
|
return DIEnumerator::get(VMContext, APInt(Value), Value.isUnsigned(), Name);
|
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DIBasicType *DIBuilder::createUnspecifiedType(StringRef Name) {
|
2011-09-14 23:13:28 +00:00
|
|
|
assert(!Name.empty() && "Unable to create type without name");
|
2015-04-29 16:38:44 +00:00
|
|
|
return DIBasicType::get(VMContext, dwarf::DW_TAG_unspecified_type, Name);
|
2011-09-14 23:13:28 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DIBasicType *DIBuilder::createNullPtrType() {
|
2013-06-27 22:50:59 +00:00
|
|
|
return createUnspecifiedType("decltype(nullptr)");
|
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DIBasicType *DIBuilder::createBasicType(StringRef Name, uint64_t SizeInBits,
|
2018-08-14 19:35:34 +00:00
|
|
|
unsigned Encoding,
|
2024-11-06 15:48:04 -08:00
|
|
|
DINode::DIFlags Flags,
|
|
|
|
uint32_t NumExtraInhabitants) {
|
2011-09-12 18:26:08 +00:00
|
|
|
assert(!Name.empty() && "Unable to create type without name");
|
2015-04-29 16:38:44 +00:00
|
|
|
return DIBasicType::get(VMContext, dwarf::DW_TAG_base_type, Name, SizeInBits,
|
2024-11-06 15:48:04 -08:00
|
|
|
0, Encoding, NumExtraInhabitants, Flags);
|
Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
2010-11-04 15:01:38 +00:00
|
|
|
}
|
|
|
|
|
2020-08-20 16:11:22 +05:30
|
|
|
DIStringType *DIBuilder::createStringType(StringRef Name, uint64_t SizeInBits) {
|
|
|
|
assert(!Name.empty() && "Unable to create type without name");
|
|
|
|
return DIStringType::get(VMContext, dwarf::DW_TAG_string_type, Name,
|
|
|
|
SizeInBits, 0);
|
|
|
|
}
|
|
|
|
|
2022-02-11 14:38:50 -05:00
|
|
|
DIStringType *DIBuilder::createStringType(StringRef Name,
|
|
|
|
DIVariable *StringLength,
|
|
|
|
DIExpression *StrLocationExp) {
|
|
|
|
assert(!Name.empty() && "Unable to create type without name");
|
|
|
|
return DIStringType::get(VMContext, dwarf::DW_TAG_string_type, Name,
|
|
|
|
StringLength, nullptr, StrLocationExp, 0, 0, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
DIStringType *DIBuilder::createStringType(StringRef Name,
|
|
|
|
DIExpression *StringLengthExp,
|
|
|
|
DIExpression *StrLocationExp) {
|
|
|
|
assert(!Name.empty() && "Unable to create type without name");
|
|
|
|
return DIStringType::get(VMContext, dwarf::DW_TAG_string_type, Name, nullptr,
|
|
|
|
StringLengthExp, StrLocationExp, 0, 0, 0);
|
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DIDerivedType *DIBuilder::createQualifiedType(unsigned Tag, DIType *FromTy) {
|
2016-04-23 21:08:00 +00:00
|
|
|
return DIDerivedType::get(VMContext, Tag, "", nullptr, 0, nullptr, FromTy, 0,
|
2024-03-19 09:13:17 +03:00
|
|
|
0, 0, std::nullopt, std::nullopt, DINode::FlagZero);
|
|
|
|
}
|
|
|
|
|
|
|
|
DIDerivedType *DIBuilder::createPtrAuthQualifiedType(
|
|
|
|
DIType *FromTy, unsigned Key, bool IsAddressDiscriminated,
|
|
|
|
unsigned ExtraDiscriminator, bool IsaPointer,
|
|
|
|
bool AuthenticatesNullValues) {
|
|
|
|
return DIDerivedType::get(VMContext, dwarf::DW_TAG_LLVM_ptrauth_type, "",
|
|
|
|
nullptr, 0, nullptr, FromTy, 0, 0, 0, std::nullopt,
|
|
|
|
std::optional<DIDerivedType::PtrAuthData>(
|
|
|
|
std::in_place, Key, IsAddressDiscriminated,
|
|
|
|
ExtraDiscriminator, IsaPointer,
|
|
|
|
AuthenticatesNullValues),
|
|
|
|
DINode::FlagZero);
|
Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
2010-11-04 15:01:38 +00:00
|
|
|
}
|
|
|
|
|
2021-11-05 11:01:31 -07:00
|
|
|
DIDerivedType *
|
|
|
|
DIBuilder::createPointerType(DIType *PointeeTy, uint64_t SizeInBits,
|
|
|
|
uint32_t AlignInBits,
|
2022-12-03 16:01:15 -06:00
|
|
|
std::optional<unsigned> DWARFAddressSpace,
|
2021-11-05 11:01:31 -07:00
|
|
|
StringRef Name, DINodeArray Annotations) {
|
2015-03-03 17:24:31 +00:00
|
|
|
// FIXME: Why is there a name here?
|
2015-04-29 16:38:44 +00:00
|
|
|
return DIDerivedType::get(VMContext, dwarf::DW_TAG_pointer_type, Name,
|
2016-04-23 21:08:00 +00:00
|
|
|
nullptr, 0, nullptr, PointeeTy, SizeInBits,
|
2024-03-19 09:13:17 +03:00
|
|
|
AlignInBits, 0, DWARFAddressSpace, std::nullopt,
|
|
|
|
DINode::FlagZero, nullptr, Annotations);
|
Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
2010-11-04 15:01:38 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DIDerivedType *DIBuilder::createMemberPointerType(DIType *PointeeTy,
|
|
|
|
DIType *Base,
|
2015-04-16 16:36:23 +00:00
|
|
|
uint64_t SizeInBits,
|
2016-10-18 14:31:22 +00:00
|
|
|
uint32_t AlignInBits,
|
2016-09-06 10:46:28 +00:00
|
|
|
DINode::DIFlags Flags) {
|
2015-04-29 16:38:44 +00:00
|
|
|
return DIDerivedType::get(VMContext, dwarf::DW_TAG_ptr_to_member_type, "",
|
2016-04-23 21:08:00 +00:00
|
|
|
nullptr, 0, nullptr, PointeeTy, SizeInBits,
|
2024-03-19 09:13:17 +03:00
|
|
|
AlignInBits, 0, std::nullopt, std::nullopt, Flags,
|
|
|
|
Base);
|
2013-01-07 05:51:15 +00:00
|
|
|
}
|
|
|
|
|
2021-11-11 13:39:50 -08:00
|
|
|
DIDerivedType *
|
|
|
|
DIBuilder::createReferenceType(unsigned Tag, DIType *RTy, uint64_t SizeInBits,
|
|
|
|
uint32_t AlignInBits,
|
2022-12-03 16:01:15 -06:00
|
|
|
std::optional<unsigned> DWARFAddressSpace) {
|
2015-04-06 23:18:49 +00:00
|
|
|
assert(RTy && "Unable to create reference type");
|
2016-04-23 21:08:00 +00:00
|
|
|
return DIDerivedType::get(VMContext, Tag, "", nullptr, 0, nullptr, RTy,
|
2024-03-19 09:13:17 +03:00
|
|
|
SizeInBits, AlignInBits, 0, DWARFAddressSpace, {},
|
2017-03-08 23:55:44 +00:00
|
|
|
DINode::FlagZero);
|
Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
2010-11-04 15:01:38 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DIDerivedType *DIBuilder::createTypedef(DIType *Ty, StringRef Name,
|
|
|
|
DIFile *File, unsigned LineNo,
|
2021-11-11 13:39:50 -08:00
|
|
|
DIScope *Context, uint32_t AlignInBits,
|
2022-09-22 16:59:00 +00:00
|
|
|
DINode::DIFlags Flags,
|
2021-09-20 17:08:46 -07:00
|
|
|
DINodeArray Annotations) {
|
2024-01-16 16:56:24 -08:00
|
|
|
return DIDerivedType::get(VMContext, dwarf::DW_TAG_typedef, Name, File,
|
|
|
|
LineNo, getNonCompileUnitScope(Context), Ty, 0,
|
2024-03-19 09:13:17 +03:00
|
|
|
AlignInBits, 0, std::nullopt, std::nullopt, Flags,
|
|
|
|
nullptr, Annotations);
|
Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
2010-11-04 15:01:38 +00:00
|
|
|
}
|
|
|
|
|
2024-04-18 12:08:31 +01:00
|
|
|
DIDerivedType *
|
|
|
|
DIBuilder::createTemplateAlias(DIType *Ty, StringRef Name, DIFile *File,
|
|
|
|
unsigned LineNo, DIScope *Context,
|
|
|
|
DINodeArray TParams, uint32_t AlignInBits,
|
|
|
|
DINode::DIFlags Flags, DINodeArray Annotations) {
|
|
|
|
return DIDerivedType::get(VMContext, dwarf::DW_TAG_template_alias, Name, File,
|
|
|
|
LineNo, getNonCompileUnitScope(Context), Ty, 0,
|
|
|
|
AlignInBits, 0, std::nullopt, std::nullopt, Flags,
|
|
|
|
TParams.get(), Annotations);
|
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DIDerivedType *DIBuilder::createFriend(DIType *Ty, DIType *FriendTy) {
|
2015-04-06 23:18:49 +00:00
|
|
|
assert(Ty && "Invalid type!");
|
|
|
|
assert(FriendTy && "Invalid friend type!");
|
2016-04-23 21:08:00 +00:00
|
|
|
return DIDerivedType::get(VMContext, dwarf::DW_TAG_friend, "", nullptr, 0, Ty,
|
2024-03-19 09:13:17 +03:00
|
|
|
FriendTy, 0, 0, 0, std::nullopt, std::nullopt,
|
|
|
|
DINode::FlagZero);
|
Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
2010-11-04 15:01:38 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DIDerivedType *DIBuilder::createInheritance(DIType *Ty, DIType *BaseTy,
|
2015-04-16 16:36:23 +00:00
|
|
|
uint64_t BaseOffset,
|
2018-05-14 21:21:22 +00:00
|
|
|
uint32_t VBPtrOffset,
|
2016-09-06 10:46:28 +00:00
|
|
|
DINode::DIFlags Flags) {
|
2015-04-06 23:18:49 +00:00
|
|
|
assert(Ty && "Unable to create inheritance");
|
2018-05-14 21:21:22 +00:00
|
|
|
Metadata *ExtraData = ConstantAsMetadata::get(
|
|
|
|
ConstantInt::get(IntegerType::get(VMContext, 32), VBPtrOffset));
|
2015-04-29 16:38:44 +00:00
|
|
|
return DIDerivedType::get(VMContext, dwarf::DW_TAG_inheritance, "", nullptr,
|
2022-12-02 20:05:20 -08:00
|
|
|
0, Ty, BaseTy, 0, 0, BaseOffset, std::nullopt,
|
2024-03-19 09:13:17 +03:00
|
|
|
std::nullopt, Flags, ExtraData);
|
Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
2010-11-04 15:01:38 +00:00
|
|
|
}
|
|
|
|
|
2021-07-19 00:12:15 -07:00
|
|
|
DIDerivedType *DIBuilder::createMemberType(
|
|
|
|
DIScope *Scope, StringRef Name, DIFile *File, unsigned LineNumber,
|
|
|
|
uint64_t SizeInBits, uint32_t AlignInBits, uint64_t OffsetInBits,
|
|
|
|
DINode::DIFlags Flags, DIType *Ty, DINodeArray Annotations) {
|
2016-04-23 21:08:00 +00:00
|
|
|
return DIDerivedType::get(VMContext, dwarf::DW_TAG_member, Name, File,
|
|
|
|
LineNumber, getNonCompileUnitScope(Scope), Ty,
|
2022-12-02 20:05:20 -08:00
|
|
|
SizeInBits, AlignInBits, OffsetInBits, std::nullopt,
|
2024-03-19 09:13:17 +03:00
|
|
|
std::nullopt, Flags, nullptr, Annotations);
|
Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
2010-11-04 15:01:38 +00:00
|
|
|
}
|
|
|
|
|
2015-03-27 00:34:10 +00:00
|
|
|
static ConstantAsMetadata *getConstantOrNull(Constant *C) {
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-09 18:38:53 +00:00
|
|
|
if (C)
|
|
|
|
return ConstantAsMetadata::get(C);
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
2018-09-12 22:57:28 +00:00
|
|
|
DIDerivedType *DIBuilder::createVariantMemberType(
|
|
|
|
DIScope *Scope, StringRef Name, DIFile *File, unsigned LineNumber,
|
|
|
|
uint64_t SizeInBits, uint32_t AlignInBits, uint64_t OffsetInBits,
|
|
|
|
Constant *Discriminant, DINode::DIFlags Flags, DIType *Ty) {
|
2024-03-19 09:13:17 +03:00
|
|
|
return DIDerivedType::get(
|
|
|
|
VMContext, dwarf::DW_TAG_member, Name, File, LineNumber,
|
|
|
|
getNonCompileUnitScope(Scope), Ty, SizeInBits, AlignInBits, OffsetInBits,
|
|
|
|
std::nullopt, std::nullopt, Flags, getConstantOrNull(Discriminant));
|
2018-02-06 23:45:59 +00:00
|
|
|
}
|
|
|
|
|
2016-06-30 03:00:20 +00:00
|
|
|
DIDerivedType *DIBuilder::createBitFieldMemberType(
|
|
|
|
DIScope *Scope, StringRef Name, DIFile *File, unsigned LineNumber,
|
2016-10-20 00:13:12 +00:00
|
|
|
uint64_t SizeInBits, uint64_t OffsetInBits, uint64_t StorageOffsetInBits,
|
2021-07-19 00:12:15 -07:00
|
|
|
DINode::DIFlags Flags, DIType *Ty, DINodeArray Annotations) {
|
2016-06-30 03:00:20 +00:00
|
|
|
Flags |= DINode::FlagBitField;
|
|
|
|
return DIDerivedType::get(
|
|
|
|
VMContext, dwarf::DW_TAG_member, Name, File, LineNumber,
|
2021-11-11 13:39:50 -08:00
|
|
|
getNonCompileUnitScope(Scope), Ty, SizeInBits, /*AlignInBits=*/0,
|
2024-03-19 09:13:17 +03:00
|
|
|
OffsetInBits, std::nullopt, std::nullopt, Flags,
|
2016-10-20 00:13:12 +00:00
|
|
|
ConstantAsMetadata::get(ConstantInt::get(IntegerType::get(VMContext, 64),
|
2021-07-19 00:12:15 -07:00
|
|
|
StorageOffsetInBits)),
|
|
|
|
Annotations);
|
2016-06-30 03:00:20 +00:00
|
|
|
}
|
|
|
|
|
2016-09-06 17:03:02 +00:00
|
|
|
DIDerivedType *
|
|
|
|
DIBuilder::createStaticMemberType(DIScope *Scope, StringRef Name, DIFile *File,
|
|
|
|
unsigned LineNumber, DIType *Ty,
|
2016-10-20 00:13:12 +00:00
|
|
|
DINode::DIFlags Flags, llvm::Constant *Val,
|
2023-11-15 09:36:47 +00:00
|
|
|
unsigned Tag, uint32_t AlignInBits) {
|
2015-04-29 16:38:44 +00:00
|
|
|
Flags |= DINode::FlagStaticMember;
|
2023-11-15 09:36:47 +00:00
|
|
|
return DIDerivedType::get(VMContext, Tag, Name, File, LineNumber,
|
|
|
|
getNonCompileUnitScope(Scope), Ty, 0, AlignInBits,
|
2024-03-19 09:13:17 +03:00
|
|
|
0, std::nullopt, std::nullopt, Flags,
|
|
|
|
getConstantOrNull(Val));
|
2013-01-16 01:22:23 +00:00
|
|
|
}
|
|
|
|
|
2016-09-06 17:03:02 +00:00
|
|
|
DIDerivedType *
|
|
|
|
DIBuilder::createObjCIVar(StringRef Name, DIFile *File, unsigned LineNumber,
|
2016-10-18 14:31:22 +00:00
|
|
|
uint64_t SizeInBits, uint32_t AlignInBits,
|
2016-09-06 17:03:02 +00:00
|
|
|
uint64_t OffsetInBits, DINode::DIFlags Flags,
|
|
|
|
DIType *Ty, MDNode *PropertyNode) {
|
2016-04-23 21:08:00 +00:00
|
|
|
return DIDerivedType::get(VMContext, dwarf::DW_TAG_member, Name, File,
|
|
|
|
LineNumber, getNonCompileUnitScope(File), Ty,
|
2022-12-02 20:05:20 -08:00
|
|
|
SizeInBits, AlignInBits, OffsetInBits, std::nullopt,
|
2024-03-19 09:13:17 +03:00
|
|
|
std::nullopt, Flags, PropertyNode);
|
2011-04-16 00:11:51 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DIObjCProperty *
|
|
|
|
DIBuilder::createObjCProperty(StringRef Name, DIFile *File, unsigned LineNumber,
|
2013-10-15 23:31:31 +00:00
|
|
|
StringRef GetterName, StringRef SetterName,
|
2015-04-29 16:38:44 +00:00
|
|
|
unsigned PropertyAttributes, DIType *Ty) {
|
|
|
|
return DIObjCProperty::get(VMContext, Name, File, LineNumber, GetterName,
|
2016-04-23 21:08:00 +00:00
|
|
|
SetterName, PropertyAttributes, Ty);
|
2012-02-04 00:59:25 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DITemplateTypeParameter *
|
|
|
|
DIBuilder::createTemplateTypeParameter(DIScope *Context, StringRef Name,
|
2020-03-02 10:52:12 +05:30
|
|
|
DIType *Ty, bool isDefault) {
|
2015-04-29 16:38:44 +00:00
|
|
|
assert((!Context || isa<DICompileUnit>(Context)) && "Expected compile unit");
|
2020-03-02 10:52:12 +05:30
|
|
|
return DITemplateTypeParameter::get(VMContext, Name, Ty, isDefault);
|
2011-02-02 21:38:25 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
static DITemplateValueParameter *
|
2015-02-13 03:35:29 +00:00
|
|
|
createTemplateValueParameterHelper(LLVMContext &VMContext, unsigned Tag,
|
2015-04-29 16:38:44 +00:00
|
|
|
DIScope *Context, StringRef Name, DIType *Ty,
|
2020-03-02 10:52:12 +05:30
|
|
|
bool IsDefault, Metadata *MD) {
|
2015-04-29 16:38:44 +00:00
|
|
|
assert((!Context || isa<DICompileUnit>(Context)) && "Expected compile unit");
|
2020-03-02 10:52:12 +05:30
|
|
|
return DITemplateValueParameter::get(VMContext, Tag, Name, Ty, IsDefault, MD);
|
2011-02-02 22:35:53 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DITemplateValueParameter *
|
|
|
|
DIBuilder::createTemplateValueParameter(DIScope *Context, StringRef Name,
|
2020-03-02 10:52:12 +05:30
|
|
|
DIType *Ty, bool isDefault,
|
|
|
|
Constant *Val) {
|
2014-11-15 00:05:04 +00:00
|
|
|
return createTemplateValueParameterHelper(
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-09 18:38:53 +00:00
|
|
|
VMContext, dwarf::DW_TAG_template_value_parameter, Context, Name, Ty,
|
2020-03-02 10:52:12 +05:30
|
|
|
isDefault, getConstantOrNull(Val));
|
2013-06-22 18:59:11 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DITemplateValueParameter *
|
|
|
|
DIBuilder::createTemplateTemplateParameter(DIScope *Context, StringRef Name,
|
2022-12-16 11:26:08 +00:00
|
|
|
DIType *Ty, StringRef Val,
|
|
|
|
bool IsDefault) {
|
2014-11-15 00:05:04 +00:00
|
|
|
return createTemplateValueParameterHelper(
|
|
|
|
VMContext, dwarf::DW_TAG_GNU_template_template_param, Context, Name, Ty,
|
2022-12-16 11:26:08 +00:00
|
|
|
IsDefault, MDString::get(VMContext, Val));
|
2013-06-22 18:59:11 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DITemplateValueParameter *
|
|
|
|
DIBuilder::createTemplateParameterPack(DIScope *Context, StringRef Name,
|
|
|
|
DIType *Ty, DINodeArray Val) {
|
2014-11-15 00:05:04 +00:00
|
|
|
return createTemplateValueParameterHelper(
|
|
|
|
VMContext, dwarf::DW_TAG_GNU_template_parameter_pack, Context, Name, Ty,
|
2020-03-02 10:52:12 +05:30
|
|
|
false, Val.get());
|
2013-06-22 18:59:11 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DICompositeType *DIBuilder::createClassType(
|
|
|
|
DIScope *Context, StringRef Name, DIFile *File, unsigned LineNumber,
|
2016-10-18 14:31:22 +00:00
|
|
|
uint64_t SizeInBits, uint32_t AlignInBits, uint64_t OffsetInBits,
|
2016-09-06 10:46:28 +00:00
|
|
|
DINode::DIFlags Flags, DIType *DerivedFrom, DINodeArray Elements,
|
2023-11-15 12:46:06 -08:00
|
|
|
unsigned RunTimeLang, DIType *VTableHolder, MDNode *TemplateParams,
|
|
|
|
StringRef UniqueIdentifier) {
|
2015-04-29 16:38:44 +00:00
|
|
|
assert((!Context || isa<DIScope>(Context)) &&
|
2013-03-11 23:21:19 +00:00
|
|
|
"createClassType should be called with a valid Context");
|
2015-04-16 16:36:23 +00:00
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
auto *R = DICompositeType::get(
|
2024-08-13 12:12:29 +02:00
|
|
|
VMContext, dwarf::DW_TAG_class_type, Name, File, LineNumber,
|
2016-04-23 21:08:00 +00:00
|
|
|
getNonCompileUnitScope(Context), DerivedFrom, SizeInBits, AlignInBits,
|
[llvm][DebugInfo] Add new DW_AT_APPLE_enum_kind to encode enum_extensibility (#124752)
When creating `EnumDecl`s from DWARF for Objective-C `NS_ENUM`s, the
Swift compiler tries to figure out if it should perform "swiftification"
of that enum (which involves renaming the enumerator cases, etc.). The
heuristics by which it determines whether we want to swiftify an enum is
by checking the `enum_extensibility` attribute (because that's what
`NS_ENUM` pretty much are). Currently LLDB fails to attach the
`EnumExtensibilityAttr` to `EnumDecl`s it creates (because there's not
enough info in DWARF to derive it), which means we have to fall back to
re-building Swift modules on-the-fly, slowing down expression evaluation
substantially. This happens around
https://github.com/swiftlang/swift/blob/4b3931c8ce437b3f13f245e6423f95c94a5876ac/lib/ClangImporter/ImportEnumInfo.cpp#L37-L59
To speed up Swift exression evaluation, this patch proposes encoding the
C/C++/Objective-C `enum_extensibility` attribute in DWARF via a new
`DW_AT_APPLE_ENUM_KIND`. This would currently be only used from the LLDB
Swift plugin. But may be of interest to other language plugins as well
(though I haven't come up with a concrete use-case for it outside of
Swift).
I'm open to naming suggestions of the various new attributes/attribute
constants proposed here. I tried to be as generic as possible if we
wanted to extend it to other kinds of enum properties (e.g., flag
enums).
The new attribute would look as follows:
```
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Closed)
DW_AT_name ("ClosedEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (23)
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Open)
DW_AT_name ("OpenEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (27)
```
Absence of the attribute means the extensibility of the enum is unknown
and abides by whatever the language rules of that CU dictate.
This does feel like a big hammer for quite a specific use-case, so I'm
happy to discuss alternatives.
Alternatives considered:
* Re-using an existing DWARF attribute to express extensibility. E.g., a
`DW_TAG_enumeration_type` could have a `DW_AT_count` or
`DW_AT_upper_bound` indicating the number of enumerators, which could
imply closed-ness. I felt like a dedicated attribute (which could be
generalized further) seemed more applicable. But I'm open to re-using
existing attributes.
* Encoding the entire attribute string (i.e., `DW_TAG_LLVM_annotation
("enum_extensibility((open))")`) on the `DW_TAG_enumeration_type`. Then
in LLDB somehow parse that out into a `EnumExtensibilityAttr`. I haven't
found a great API in Clang to parse arbitrary strings into AST nodes
(the ones I've found required fully formed C++ constructs). Though if
someone knows of a good way to do this, happy to consider that too.
2025-02-06 08:58:35 +00:00
|
|
|
OffsetInBits, Flags, Elements, RunTimeLang, /*EnumKind=*/std::nullopt,
|
|
|
|
VTableHolder, cast_or_null<MDTuple>(TemplateParams), UniqueIdentifier);
|
2015-02-17 19:17:39 +00:00
|
|
|
trackIfUnresolved(R);
|
2013-03-11 23:21:19 +00:00
|
|
|
return R;
|
2012-07-06 02:35:57 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DICompositeType *DIBuilder::createStructType(
|
|
|
|
DIScope *Context, StringRef Name, DIFile *File, unsigned LineNumber,
|
2016-10-18 14:31:22 +00:00
|
|
|
uint64_t SizeInBits, uint32_t AlignInBits, DINode::DIFlags Flags,
|
2015-04-29 16:38:44 +00:00
|
|
|
DIType *DerivedFrom, DINodeArray Elements, unsigned RunTimeLang,
|
2024-11-13 09:55:37 -08:00
|
|
|
DIType *VTableHolder, StringRef UniqueIdentifier, DIType *Specification,
|
2024-11-06 15:48:04 -08:00
|
|
|
uint32_t NumExtraInhabitants) {
|
2015-04-29 16:38:44 +00:00
|
|
|
auto *R = DICompositeType::get(
|
2015-03-03 17:24:31 +00:00
|
|
|
VMContext, dwarf::DW_TAG_structure_type, Name, File, LineNumber,
|
2016-04-23 21:08:00 +00:00
|
|
|
getNonCompileUnitScope(Context), DerivedFrom, SizeInBits, AlignInBits, 0,
|
[llvm][DebugInfo] Add new DW_AT_APPLE_enum_kind to encode enum_extensibility (#124752)
When creating `EnumDecl`s from DWARF for Objective-C `NS_ENUM`s, the
Swift compiler tries to figure out if it should perform "swiftification"
of that enum (which involves renaming the enumerator cases, etc.). The
heuristics by which it determines whether we want to swiftify an enum is
by checking the `enum_extensibility` attribute (because that's what
`NS_ENUM` pretty much are). Currently LLDB fails to attach the
`EnumExtensibilityAttr` to `EnumDecl`s it creates (because there's not
enough info in DWARF to derive it), which means we have to fall back to
re-building Swift modules on-the-fly, slowing down expression evaluation
substantially. This happens around
https://github.com/swiftlang/swift/blob/4b3931c8ce437b3f13f245e6423f95c94a5876ac/lib/ClangImporter/ImportEnumInfo.cpp#L37-L59
To speed up Swift exression evaluation, this patch proposes encoding the
C/C++/Objective-C `enum_extensibility` attribute in DWARF via a new
`DW_AT_APPLE_ENUM_KIND`. This would currently be only used from the LLDB
Swift plugin. But may be of interest to other language plugins as well
(though I haven't come up with a concrete use-case for it outside of
Swift).
I'm open to naming suggestions of the various new attributes/attribute
constants proposed here. I tried to be as generic as possible if we
wanted to extend it to other kinds of enum properties (e.g., flag
enums).
The new attribute would look as follows:
```
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Closed)
DW_AT_name ("ClosedEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (23)
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Open)
DW_AT_name ("OpenEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (27)
```
Absence of the attribute means the extensibility of the enum is unknown
and abides by whatever the language rules of that CU dictate.
This does feel like a big hammer for quite a specific use-case, so I'm
happy to discuss alternatives.
Alternatives considered:
* Re-using an existing DWARF attribute to express extensibility. E.g., a
`DW_TAG_enumeration_type` could have a `DW_AT_count` or
`DW_AT_upper_bound` indicating the number of enumerators, which could
imply closed-ness. I felt like a dedicated attribute (which could be
generalized further) seemed more applicable. But I'm open to re-using
existing attributes.
* Encoding the entire attribute string (i.e., `DW_TAG_LLVM_annotation
("enum_extensibility((open))")`) on the `DW_TAG_enumeration_type`. Then
in LLDB somehow parse that out into a `EnumExtensibilityAttr`. I haven't
found a great API in Clang to parse arbitrary strings into AST nodes
(the ones I've found required fully formed C++ constructs). Though if
someone knows of a good way to do this, happy to consider that too.
2025-02-06 08:58:35 +00:00
|
|
|
Flags, Elements, RunTimeLang, /*EnumKind=*/std::nullopt, VTableHolder,
|
|
|
|
nullptr, UniqueIdentifier, nullptr, nullptr, nullptr, nullptr, nullptr,
|
|
|
|
nullptr, Specification, NumExtraInhabitants);
|
2015-02-17 19:17:39 +00:00
|
|
|
trackIfUnresolved(R);
|
2013-03-11 23:21:19 +00:00
|
|
|
return R;
|
2010-12-07 23:25:47 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DICompositeType *DIBuilder::createUnionType(
|
|
|
|
DIScope *Scope, StringRef Name, DIFile *File, unsigned LineNumber,
|
2016-10-18 14:31:22 +00:00
|
|
|
uint64_t SizeInBits, uint32_t AlignInBits, DINode::DIFlags Flags,
|
2015-04-29 16:38:44 +00:00
|
|
|
DINodeArray Elements, unsigned RunTimeLang, StringRef UniqueIdentifier) {
|
|
|
|
auto *R = DICompositeType::get(
|
2015-03-03 17:24:31 +00:00
|
|
|
VMContext, dwarf::DW_TAG_union_type, Name, File, LineNumber,
|
2016-04-23 21:08:00 +00:00
|
|
|
getNonCompileUnitScope(Scope), nullptr, SizeInBits, AlignInBits, 0, Flags,
|
[llvm][DebugInfo] Add new DW_AT_APPLE_enum_kind to encode enum_extensibility (#124752)
When creating `EnumDecl`s from DWARF for Objective-C `NS_ENUM`s, the
Swift compiler tries to figure out if it should perform "swiftification"
of that enum (which involves renaming the enumerator cases, etc.). The
heuristics by which it determines whether we want to swiftify an enum is
by checking the `enum_extensibility` attribute (because that's what
`NS_ENUM` pretty much are). Currently LLDB fails to attach the
`EnumExtensibilityAttr` to `EnumDecl`s it creates (because there's not
enough info in DWARF to derive it), which means we have to fall back to
re-building Swift modules on-the-fly, slowing down expression evaluation
substantially. This happens around
https://github.com/swiftlang/swift/blob/4b3931c8ce437b3f13f245e6423f95c94a5876ac/lib/ClangImporter/ImportEnumInfo.cpp#L37-L59
To speed up Swift exression evaluation, this patch proposes encoding the
C/C++/Objective-C `enum_extensibility` attribute in DWARF via a new
`DW_AT_APPLE_ENUM_KIND`. This would currently be only used from the LLDB
Swift plugin. But may be of interest to other language plugins as well
(though I haven't come up with a concrete use-case for it outside of
Swift).
I'm open to naming suggestions of the various new attributes/attribute
constants proposed here. I tried to be as generic as possible if we
wanted to extend it to other kinds of enum properties (e.g., flag
enums).
The new attribute would look as follows:
```
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Closed)
DW_AT_name ("ClosedEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (23)
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Open)
DW_AT_name ("OpenEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (27)
```
Absence of the attribute means the extensibility of the enum is unknown
and abides by whatever the language rules of that CU dictate.
This does feel like a big hammer for quite a specific use-case, so I'm
happy to discuss alternatives.
Alternatives considered:
* Re-using an existing DWARF attribute to express extensibility. E.g., a
`DW_TAG_enumeration_type` could have a `DW_AT_count` or
`DW_AT_upper_bound` indicating the number of enumerators, which could
imply closed-ness. I felt like a dedicated attribute (which could be
generalized further) seemed more applicable. But I'm open to re-using
existing attributes.
* Encoding the entire attribute string (i.e., `DW_TAG_LLVM_annotation
("enum_extensibility((open))")`) on the `DW_TAG_enumeration_type`. Then
in LLDB somehow parse that out into a `EnumExtensibilityAttr`. I haven't
found a great API in Clang to parse arbitrary strings into AST nodes
(the ones I've found required fully formed C++ constructs). Though if
someone knows of a good way to do this, happy to consider that too.
2025-02-06 08:58:35 +00:00
|
|
|
Elements, RunTimeLang, /*EnumKind=*/std::nullopt, nullptr, nullptr,
|
|
|
|
UniqueIdentifier);
|
2015-02-17 19:17:39 +00:00
|
|
|
trackIfUnresolved(R);
|
2013-08-29 23:17:54 +00:00
|
|
|
return R;
|
2010-12-08 01:50:15 +00:00
|
|
|
}
|
|
|
|
|
2021-11-11 13:39:50 -08:00
|
|
|
DICompositeType *
|
|
|
|
DIBuilder::createVariantPart(DIScope *Scope, StringRef Name, DIFile *File,
|
|
|
|
unsigned LineNumber, uint64_t SizeInBits,
|
|
|
|
uint32_t AlignInBits, DINode::DIFlags Flags,
|
|
|
|
DIDerivedType *Discriminator, DINodeArray Elements,
|
|
|
|
StringRef UniqueIdentifier) {
|
2018-02-06 23:45:59 +00:00
|
|
|
auto *R = DICompositeType::get(
|
|
|
|
VMContext, dwarf::DW_TAG_variant_part, Name, File, LineNumber,
|
|
|
|
getNonCompileUnitScope(Scope), nullptr, SizeInBits, AlignInBits, 0, Flags,
|
[llvm][DebugInfo] Add new DW_AT_APPLE_enum_kind to encode enum_extensibility (#124752)
When creating `EnumDecl`s from DWARF for Objective-C `NS_ENUM`s, the
Swift compiler tries to figure out if it should perform "swiftification"
of that enum (which involves renaming the enumerator cases, etc.). The
heuristics by which it determines whether we want to swiftify an enum is
by checking the `enum_extensibility` attribute (because that's what
`NS_ENUM` pretty much are). Currently LLDB fails to attach the
`EnumExtensibilityAttr` to `EnumDecl`s it creates (because there's not
enough info in DWARF to derive it), which means we have to fall back to
re-building Swift modules on-the-fly, slowing down expression evaluation
substantially. This happens around
https://github.com/swiftlang/swift/blob/4b3931c8ce437b3f13f245e6423f95c94a5876ac/lib/ClangImporter/ImportEnumInfo.cpp#L37-L59
To speed up Swift exression evaluation, this patch proposes encoding the
C/C++/Objective-C `enum_extensibility` attribute in DWARF via a new
`DW_AT_APPLE_ENUM_KIND`. This would currently be only used from the LLDB
Swift plugin. But may be of interest to other language plugins as well
(though I haven't come up with a concrete use-case for it outside of
Swift).
I'm open to naming suggestions of the various new attributes/attribute
constants proposed here. I tried to be as generic as possible if we
wanted to extend it to other kinds of enum properties (e.g., flag
enums).
The new attribute would look as follows:
```
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Closed)
DW_AT_name ("ClosedEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (23)
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Open)
DW_AT_name ("OpenEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (27)
```
Absence of the attribute means the extensibility of the enum is unknown
and abides by whatever the language rules of that CU dictate.
This does feel like a big hammer for quite a specific use-case, so I'm
happy to discuss alternatives.
Alternatives considered:
* Re-using an existing DWARF attribute to express extensibility. E.g., a
`DW_TAG_enumeration_type` could have a `DW_AT_count` or
`DW_AT_upper_bound` indicating the number of enumerators, which could
imply closed-ness. I felt like a dedicated attribute (which could be
generalized further) seemed more applicable. But I'm open to re-using
existing attributes.
* Encoding the entire attribute string (i.e., `DW_TAG_LLVM_annotation
("enum_extensibility((open))")`) on the `DW_TAG_enumeration_type`. Then
in LLDB somehow parse that out into a `EnumExtensibilityAttr`. I haven't
found a great API in Clang to parse arbitrary strings into AST nodes
(the ones I've found required fully formed C++ constructs). Though if
someone knows of a good way to do this, happy to consider that too.
2025-02-06 08:58:35 +00:00
|
|
|
Elements, 0, /*EnumKind=*/std::nullopt, nullptr, nullptr,
|
|
|
|
UniqueIdentifier, Discriminator);
|
2018-02-06 23:45:59 +00:00
|
|
|
trackIfUnresolved(R);
|
|
|
|
return R;
|
|
|
|
}
|
|
|
|
|
2015-10-15 06:56:10 +00:00
|
|
|
DISubroutineType *DIBuilder::createSubroutineType(DITypeRefArray ParameterTypes,
|
2016-09-06 17:03:02 +00:00
|
|
|
DINode::DIFlags Flags,
|
|
|
|
unsigned CC) {
|
2016-06-08 20:34:29 +00:00
|
|
|
return DISubroutineType::get(VMContext, Flags, CC, ParameterTypes);
|
2010-12-08 01:50:15 +00:00
|
|
|
}
|
|
|
|
|
[llvm][DebugInfo] Add new DW_AT_APPLE_enum_kind to encode enum_extensibility (#124752)
When creating `EnumDecl`s from DWARF for Objective-C `NS_ENUM`s, the
Swift compiler tries to figure out if it should perform "swiftification"
of that enum (which involves renaming the enumerator cases, etc.). The
heuristics by which it determines whether we want to swiftify an enum is
by checking the `enum_extensibility` attribute (because that's what
`NS_ENUM` pretty much are). Currently LLDB fails to attach the
`EnumExtensibilityAttr` to `EnumDecl`s it creates (because there's not
enough info in DWARF to derive it), which means we have to fall back to
re-building Swift modules on-the-fly, slowing down expression evaluation
substantially. This happens around
https://github.com/swiftlang/swift/blob/4b3931c8ce437b3f13f245e6423f95c94a5876ac/lib/ClangImporter/ImportEnumInfo.cpp#L37-L59
To speed up Swift exression evaluation, this patch proposes encoding the
C/C++/Objective-C `enum_extensibility` attribute in DWARF via a new
`DW_AT_APPLE_ENUM_KIND`. This would currently be only used from the LLDB
Swift plugin. But may be of interest to other language plugins as well
(though I haven't come up with a concrete use-case for it outside of
Swift).
I'm open to naming suggestions of the various new attributes/attribute
constants proposed here. I tried to be as generic as possible if we
wanted to extend it to other kinds of enum properties (e.g., flag
enums).
The new attribute would look as follows:
```
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Closed)
DW_AT_name ("ClosedEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (23)
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Open)
DW_AT_name ("OpenEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (27)
```
Absence of the attribute means the extensibility of the enum is unknown
and abides by whatever the language rules of that CU dictate.
This does feel like a big hammer for quite a specific use-case, so I'm
happy to discuss alternatives.
Alternatives considered:
* Re-using an existing DWARF attribute to express extensibility. E.g., a
`DW_TAG_enumeration_type` could have a `DW_AT_count` or
`DW_AT_upper_bound` indicating the number of enumerators, which could
imply closed-ness. I felt like a dedicated attribute (which could be
generalized further) seemed more applicable. But I'm open to re-using
existing attributes.
* Encoding the entire attribute string (i.e., `DW_TAG_LLVM_annotation
("enum_extensibility((open))")`) on the `DW_TAG_enumeration_type`. Then
in LLDB somehow parse that out into a `EnumExtensibilityAttr`. I haven't
found a great API in Clang to parse arbitrary strings into AST nodes
(the ones I've found required fully formed C++ constructs). Though if
someone knows of a good way to do this, happy to consider that too.
2025-02-06 08:58:35 +00:00
|
|
|
DICompositeType *DIBuilder::createEnumerationType(
|
|
|
|
DIScope *Scope, StringRef Name, DIFile *File, unsigned LineNumber,
|
|
|
|
uint64_t SizeInBits, uint32_t AlignInBits, DINodeArray Elements,
|
|
|
|
DIType *UnderlyingType, unsigned RunTimeLang, StringRef UniqueIdentifier,
|
|
|
|
bool IsScoped, std::optional<uint32_t> EnumKind) {
|
2015-04-29 16:38:44 +00:00
|
|
|
auto *CTy = DICompositeType::get(
|
2015-03-03 17:24:31 +00:00
|
|
|
VMContext, dwarf::DW_TAG_enumeration_type, Name, File, LineNumber,
|
2016-04-23 21:08:00 +00:00
|
|
|
getNonCompileUnitScope(Scope), UnderlyingType, SizeInBits, AlignInBits, 0,
|
2023-11-15 12:46:06 -08:00
|
|
|
IsScoped ? DINode::FlagEnumClass : DINode::FlagZero, Elements,
|
[llvm][DebugInfo] Add new DW_AT_APPLE_enum_kind to encode enum_extensibility (#124752)
When creating `EnumDecl`s from DWARF for Objective-C `NS_ENUM`s, the
Swift compiler tries to figure out if it should perform "swiftification"
of that enum (which involves renaming the enumerator cases, etc.). The
heuristics by which it determines whether we want to swiftify an enum is
by checking the `enum_extensibility` attribute (because that's what
`NS_ENUM` pretty much are). Currently LLDB fails to attach the
`EnumExtensibilityAttr` to `EnumDecl`s it creates (because there's not
enough info in DWARF to derive it), which means we have to fall back to
re-building Swift modules on-the-fly, slowing down expression evaluation
substantially. This happens around
https://github.com/swiftlang/swift/blob/4b3931c8ce437b3f13f245e6423f95c94a5876ac/lib/ClangImporter/ImportEnumInfo.cpp#L37-L59
To speed up Swift exression evaluation, this patch proposes encoding the
C/C++/Objective-C `enum_extensibility` attribute in DWARF via a new
`DW_AT_APPLE_ENUM_KIND`. This would currently be only used from the LLDB
Swift plugin. But may be of interest to other language plugins as well
(though I haven't come up with a concrete use-case for it outside of
Swift).
I'm open to naming suggestions of the various new attributes/attribute
constants proposed here. I tried to be as generic as possible if we
wanted to extend it to other kinds of enum properties (e.g., flag
enums).
The new attribute would look as follows:
```
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Closed)
DW_AT_name ("ClosedEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (23)
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Open)
DW_AT_name ("OpenEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (27)
```
Absence of the attribute means the extensibility of the enum is unknown
and abides by whatever the language rules of that CU dictate.
This does feel like a big hammer for quite a specific use-case, so I'm
happy to discuss alternatives.
Alternatives considered:
* Re-using an existing DWARF attribute to express extensibility. E.g., a
`DW_TAG_enumeration_type` could have a `DW_AT_count` or
`DW_AT_upper_bound` indicating the number of enumerators, which could
imply closed-ness. I felt like a dedicated attribute (which could be
generalized further) seemed more applicable. But I'm open to re-using
existing attributes.
* Encoding the entire attribute string (i.e., `DW_TAG_LLVM_annotation
("enum_extensibility((open))")`) on the `DW_TAG_enumeration_type`. Then
in LLDB somehow parse that out into a `EnumExtensibilityAttr`. I haven't
found a great API in Clang to parse arbitrary strings into AST nodes
(the ones I've found required fully formed C++ constructs). Though if
someone knows of a good way to do this, happy to consider that too.
2025-02-06 08:58:35 +00:00
|
|
|
RunTimeLang, EnumKind, nullptr, nullptr, UniqueIdentifier);
|
2024-01-16 16:56:24 -08:00
|
|
|
AllEnumTypes.emplace_back(CTy);
|
2015-02-17 19:17:39 +00:00
|
|
|
trackIfUnresolved(CTy);
|
2013-11-18 23:33:32 +00:00
|
|
|
return CTy;
|
2010-12-08 01:50:15 +00:00
|
|
|
}
|
|
|
|
|
2021-03-29 15:02:25 -07:00
|
|
|
DIDerivedType *DIBuilder::createSetType(DIScope *Scope, StringRef Name,
|
|
|
|
DIFile *File, unsigned LineNo,
|
|
|
|
uint64_t SizeInBits,
|
|
|
|
uint32_t AlignInBits, DIType *Ty) {
|
2024-03-19 09:13:17 +03:00
|
|
|
auto *R = DIDerivedType::get(VMContext, dwarf::DW_TAG_set_type, Name, File,
|
|
|
|
LineNo, getNonCompileUnitScope(Scope), Ty,
|
|
|
|
SizeInBits, AlignInBits, 0, std::nullopt,
|
|
|
|
std::nullopt, DINode::FlagZero);
|
2021-03-29 15:02:25 -07:00
|
|
|
trackIfUnresolved(R);
|
|
|
|
return R;
|
|
|
|
}
|
|
|
|
|
2021-11-11 13:39:50 -08:00
|
|
|
DICompositeType *
|
|
|
|
DIBuilder::createArrayType(uint64_t Size, uint32_t AlignInBits, DIType *Ty,
|
|
|
|
DINodeArray Subscripts,
|
|
|
|
PointerUnion<DIExpression *, DIVariable *> DL,
|
|
|
|
PointerUnion<DIExpression *, DIVariable *> AS,
|
|
|
|
PointerUnion<DIExpression *, DIVariable *> AL,
|
|
|
|
PointerUnion<DIExpression *, DIVariable *> RK) {
|
2025-02-21 13:17:06 -07:00
|
|
|
return createArrayType(nullptr, StringRef(), nullptr, 0, Size, AlignInBits,
|
|
|
|
Ty, Subscripts, DL, AS, AL, RK);
|
|
|
|
}
|
|
|
|
|
|
|
|
DICompositeType *DIBuilder::createArrayType(
|
|
|
|
DIScope *Scope, StringRef Name, DIFile *File, unsigned LineNumber,
|
|
|
|
uint64_t Size, uint32_t AlignInBits, DIType *Ty, DINodeArray Subscripts,
|
|
|
|
PointerUnion<DIExpression *, DIVariable *> DL,
|
|
|
|
PointerUnion<DIExpression *, DIVariable *> AS,
|
|
|
|
PointerUnion<DIExpression *, DIVariable *> AL,
|
|
|
|
PointerUnion<DIExpression *, DIVariable *> RK) {
|
2020-10-28 12:26:44 -07:00
|
|
|
auto *R = DICompositeType::get(
|
2025-02-21 13:17:06 -07:00
|
|
|
VMContext, dwarf::DW_TAG_array_type, Name, File, LineNumber,
|
|
|
|
getNonCompileUnitScope(Scope), Ty, Size, AlignInBits, 0, DINode::FlagZero,
|
|
|
|
Subscripts, 0, /*EnumKind=*/std::nullopt, nullptr, nullptr, "", nullptr,
|
2023-04-15 21:16:16 -05:00
|
|
|
isa<DIExpression *>(DL) ? (Metadata *)cast<DIExpression *>(DL)
|
|
|
|
: (Metadata *)cast<DIVariable *>(DL),
|
|
|
|
isa<DIExpression *>(AS) ? (Metadata *)cast<DIExpression *>(AS)
|
|
|
|
: (Metadata *)cast<DIVariable *>(AS),
|
|
|
|
isa<DIExpression *>(AL) ? (Metadata *)cast<DIExpression *>(AL)
|
|
|
|
: (Metadata *)cast<DIVariable *>(AL),
|
|
|
|
isa<DIExpression *>(RK) ? (Metadata *)cast<DIExpression *>(RK)
|
|
|
|
: (Metadata *)cast<DIVariable *>(RK));
|
2015-02-17 19:17:39 +00:00
|
|
|
trackIfUnresolved(R);
|
|
|
|
return R;
|
2010-12-08 01:50:15 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DICompositeType *DIBuilder::createVectorType(uint64_t Size,
|
2016-10-18 14:31:22 +00:00
|
|
|
uint32_t AlignInBits, DIType *Ty,
|
2015-04-29 16:38:44 +00:00
|
|
|
DINodeArray Subscripts) {
|
2016-04-23 21:08:00 +00:00
|
|
|
auto *R = DICompositeType::get(VMContext, dwarf::DW_TAG_array_type, "",
|
|
|
|
nullptr, 0, nullptr, Ty, Size, AlignInBits, 0,
|
[llvm][DebugInfo] Add new DW_AT_APPLE_enum_kind to encode enum_extensibility (#124752)
When creating `EnumDecl`s from DWARF for Objective-C `NS_ENUM`s, the
Swift compiler tries to figure out if it should perform "swiftification"
of that enum (which involves renaming the enumerator cases, etc.). The
heuristics by which it determines whether we want to swiftify an enum is
by checking the `enum_extensibility` attribute (because that's what
`NS_ENUM` pretty much are). Currently LLDB fails to attach the
`EnumExtensibilityAttr` to `EnumDecl`s it creates (because there's not
enough info in DWARF to derive it), which means we have to fall back to
re-building Swift modules on-the-fly, slowing down expression evaluation
substantially. This happens around
https://github.com/swiftlang/swift/blob/4b3931c8ce437b3f13f245e6423f95c94a5876ac/lib/ClangImporter/ImportEnumInfo.cpp#L37-L59
To speed up Swift exression evaluation, this patch proposes encoding the
C/C++/Objective-C `enum_extensibility` attribute in DWARF via a new
`DW_AT_APPLE_ENUM_KIND`. This would currently be only used from the LLDB
Swift plugin. But may be of interest to other language plugins as well
(though I haven't come up with a concrete use-case for it outside of
Swift).
I'm open to naming suggestions of the various new attributes/attribute
constants proposed here. I tried to be as generic as possible if we
wanted to extend it to other kinds of enum properties (e.g., flag
enums).
The new attribute would look as follows:
```
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Closed)
DW_AT_name ("ClosedEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (23)
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Open)
DW_AT_name ("OpenEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (27)
```
Absence of the attribute means the extensibility of the enum is unknown
and abides by whatever the language rules of that CU dictate.
This does feel like a big hammer for quite a specific use-case, so I'm
happy to discuss alternatives.
Alternatives considered:
* Re-using an existing DWARF attribute to express extensibility. E.g., a
`DW_TAG_enumeration_type` could have a `DW_AT_count` or
`DW_AT_upper_bound` indicating the number of enumerators, which could
imply closed-ness. I felt like a dedicated attribute (which could be
generalized further) seemed more applicable. But I'm open to re-using
existing attributes.
* Encoding the entire attribute string (i.e., `DW_TAG_LLVM_annotation
("enum_extensibility((open))")`) on the `DW_TAG_enumeration_type`. Then
in LLDB somehow parse that out into a `EnumExtensibilityAttr`. I haven't
found a great API in Clang to parse arbitrary strings into AST nodes
(the ones I've found required fully formed C++ constructs). Though if
someone knows of a good way to do this, happy to consider that too.
2025-02-06 08:58:35 +00:00
|
|
|
DINode::FlagVector, Subscripts, 0,
|
|
|
|
/*EnumKind=*/std::nullopt, nullptr);
|
2015-02-17 19:17:39 +00:00
|
|
|
trackIfUnresolved(R);
|
|
|
|
return R;
|
2010-12-08 01:50:15 +00:00
|
|
|
}
|
2010-12-07 23:25:47 +00:00
|
|
|
|
2018-06-01 23:15:09 +00:00
|
|
|
DISubprogram *DIBuilder::createArtificialSubprogram(DISubprogram *SP) {
|
|
|
|
auto NewSP = SP->cloneWithFlags(SP->getFlags() | DINode::FlagArtificial);
|
|
|
|
return MDNode::replaceWithDistinct(std::move(NewSP));
|
|
|
|
}
|
|
|
|
|
|
|
|
static DIType *createTypeWithFlags(const DIType *Ty,
|
2016-09-06 10:46:28 +00:00
|
|
|
DINode::DIFlags FlagsToSet) {
|
2018-06-01 23:15:09 +00:00
|
|
|
auto NewTy = Ty->cloneWithFlags(Ty->getFlags() | FlagsToSet);
|
2015-03-03 17:24:31 +00:00
|
|
|
return MDNode::replaceWithUniqued(std::move(NewTy));
|
2014-10-03 20:01:09 +00:00
|
|
|
}
|
2014-10-02 22:15:31 +00:00
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DIType *DIBuilder::createArtificialType(DIType *Ty) {
|
2015-03-03 17:24:31 +00:00
|
|
|
// FIXME: Restrict this to the nodes where it's valid.
|
2015-04-16 01:01:28 +00:00
|
|
|
if (Ty->isArtificial())
|
2014-10-03 20:01:09 +00:00
|
|
|
return Ty;
|
2018-06-01 23:15:09 +00:00
|
|
|
return createTypeWithFlags(Ty, DINode::FlagArtificial);
|
Introduce DIBuilder. It is intended to be a front-end friendly interface to emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
2010-11-04 15:01:38 +00:00
|
|
|
}
|
2010-12-07 23:25:47 +00:00
|
|
|
|
2025-01-18 10:20:15 +00:00
|
|
|
DIType *DIBuilder::createObjectPointerType(DIType *Ty, bool Implicit) {
|
2015-03-03 17:24:31 +00:00
|
|
|
// FIXME: Restrict this to the nodes where it's valid.
|
2015-04-16 01:01:28 +00:00
|
|
|
if (Ty->isObjectPointer())
|
2012-09-12 23:36:19 +00:00
|
|
|
return Ty;
|
2025-01-18 10:20:15 +00:00
|
|
|
DINode::DIFlags Flags = DINode::FlagObjectPointer;
|
|
|
|
|
|
|
|
if (Implicit)
|
|
|
|
Flags |= DINode::FlagArtificial;
|
|
|
|
|
2018-06-01 23:15:09 +00:00
|
|
|
return createTypeWithFlags(Ty, Flags);
|
2012-09-12 23:36:19 +00:00
|
|
|
}
|
|
|
|
|
2016-04-15 15:57:41 +00:00
|
|
|
void DIBuilder::retainType(DIScope *T) {
|
2015-04-16 01:01:28 +00:00
|
|
|
assert(T && "Expected non-null type");
|
2016-04-15 15:57:41 +00:00
|
|
|
assert((isa<DIType>(T) || (isa<DISubprogram>(T) &&
|
|
|
|
cast<DISubprogram>(T)->isDefinition() == false)) &&
|
|
|
|
"Expected type or subprogram declaration");
|
2024-01-16 16:56:24 -08:00
|
|
|
AllRetainTypes.emplace_back(T);
|
2015-03-27 23:00:49 +00:00
|
|
|
}
|
2010-12-08 01:50:15 +00:00
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DIBasicType *DIBuilder::createUnspecifiedParameter() { return nullptr; }
|
2010-12-08 01:50:15 +00:00
|
|
|
|
[llvm][DebugInfo] Add new DW_AT_APPLE_enum_kind to encode enum_extensibility (#124752)
When creating `EnumDecl`s from DWARF for Objective-C `NS_ENUM`s, the
Swift compiler tries to figure out if it should perform "swiftification"
of that enum (which involves renaming the enumerator cases, etc.). The
heuristics by which it determines whether we want to swiftify an enum is
by checking the `enum_extensibility` attribute (because that's what
`NS_ENUM` pretty much are). Currently LLDB fails to attach the
`EnumExtensibilityAttr` to `EnumDecl`s it creates (because there's not
enough info in DWARF to derive it), which means we have to fall back to
re-building Swift modules on-the-fly, slowing down expression evaluation
substantially. This happens around
https://github.com/swiftlang/swift/blob/4b3931c8ce437b3f13f245e6423f95c94a5876ac/lib/ClangImporter/ImportEnumInfo.cpp#L37-L59
To speed up Swift exression evaluation, this patch proposes encoding the
C/C++/Objective-C `enum_extensibility` attribute in DWARF via a new
`DW_AT_APPLE_ENUM_KIND`. This would currently be only used from the LLDB
Swift plugin. But may be of interest to other language plugins as well
(though I haven't come up with a concrete use-case for it outside of
Swift).
I'm open to naming suggestions of the various new attributes/attribute
constants proposed here. I tried to be as generic as possible if we
wanted to extend it to other kinds of enum properties (e.g., flag
enums).
The new attribute would look as follows:
```
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Closed)
DW_AT_name ("ClosedEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (23)
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Open)
DW_AT_name ("OpenEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (27)
```
Absence of the attribute means the extensibility of the enum is unknown
and abides by whatever the language rules of that CU dictate.
This does feel like a big hammer for quite a specific use-case, so I'm
happy to discuss alternatives.
Alternatives considered:
* Re-using an existing DWARF attribute to express extensibility. E.g., a
`DW_TAG_enumeration_type` could have a `DW_AT_count` or
`DW_AT_upper_bound` indicating the number of enumerators, which could
imply closed-ness. I felt like a dedicated attribute (which could be
generalized further) seemed more applicable. But I'm open to re-using
existing attributes.
* Encoding the entire attribute string (i.e., `DW_TAG_LLVM_annotation
("enum_extensibility((open))")`) on the `DW_TAG_enumeration_type`. Then
in LLDB somehow parse that out into a `EnumExtensibilityAttr`. I haven't
found a great API in Clang to parse arbitrary strings into AST nodes
(the ones I've found required fully formed C++ constructs). Though if
someone knows of a good way to do this, happy to consider that too.
2025-02-06 08:58:35 +00:00
|
|
|
DICompositeType *DIBuilder::createForwardDecl(
|
|
|
|
unsigned Tag, StringRef Name, DIScope *Scope, DIFile *F, unsigned Line,
|
|
|
|
unsigned RuntimeLang, uint64_t SizeInBits, uint32_t AlignInBits,
|
|
|
|
StringRef UniqueIdentifier, std::optional<uint32_t> EnumKind) {
|
2015-03-03 17:24:31 +00:00
|
|
|
// FIXME: Define in terms of createReplaceableForwardDecl() by calling
|
|
|
|
// replaceWithUniqued().
|
2015-04-29 16:38:44 +00:00
|
|
|
auto *RetTy = DICompositeType::get(
|
2016-04-23 21:08:00 +00:00
|
|
|
VMContext, Tag, Name, F, Line, getNonCompileUnitScope(Scope), nullptr,
|
|
|
|
SizeInBits, AlignInBits, 0, DINode::FlagFwdDecl, nullptr, RuntimeLang,
|
[llvm][DebugInfo] Add new DW_AT_APPLE_enum_kind to encode enum_extensibility (#124752)
When creating `EnumDecl`s from DWARF for Objective-C `NS_ENUM`s, the
Swift compiler tries to figure out if it should perform "swiftification"
of that enum (which involves renaming the enumerator cases, etc.). The
heuristics by which it determines whether we want to swiftify an enum is
by checking the `enum_extensibility` attribute (because that's what
`NS_ENUM` pretty much are). Currently LLDB fails to attach the
`EnumExtensibilityAttr` to `EnumDecl`s it creates (because there's not
enough info in DWARF to derive it), which means we have to fall back to
re-building Swift modules on-the-fly, slowing down expression evaluation
substantially. This happens around
https://github.com/swiftlang/swift/blob/4b3931c8ce437b3f13f245e6423f95c94a5876ac/lib/ClangImporter/ImportEnumInfo.cpp#L37-L59
To speed up Swift exression evaluation, this patch proposes encoding the
C/C++/Objective-C `enum_extensibility` attribute in DWARF via a new
`DW_AT_APPLE_ENUM_KIND`. This would currently be only used from the LLDB
Swift plugin. But may be of interest to other language plugins as well
(though I haven't come up with a concrete use-case for it outside of
Swift).
I'm open to naming suggestions of the various new attributes/attribute
constants proposed here. I tried to be as generic as possible if we
wanted to extend it to other kinds of enum properties (e.g., flag
enums).
The new attribute would look as follows:
```
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Closed)
DW_AT_name ("ClosedEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (23)
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Open)
DW_AT_name ("OpenEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (27)
```
Absence of the attribute means the extensibility of the enum is unknown
and abides by whatever the language rules of that CU dictate.
This does feel like a big hammer for quite a specific use-case, so I'm
happy to discuss alternatives.
Alternatives considered:
* Re-using an existing DWARF attribute to express extensibility. E.g., a
`DW_TAG_enumeration_type` could have a `DW_AT_count` or
`DW_AT_upper_bound` indicating the number of enumerators, which could
imply closed-ness. I felt like a dedicated attribute (which could be
generalized further) seemed more applicable. But I'm open to re-using
existing attributes.
* Encoding the entire attribute string (i.e., `DW_TAG_LLVM_annotation
("enum_extensibility((open))")`) on the `DW_TAG_enumeration_type`. Then
in LLDB somehow parse that out into a `EnumExtensibilityAttr`. I haven't
found a great API in Clang to parse arbitrary strings into AST nodes
(the ones I've found required fully formed C++ constructs). Though if
someone knows of a good way to do this, happy to consider that too.
2025-02-06 08:58:35 +00:00
|
|
|
/*EnumKind=*/EnumKind, nullptr, nullptr, UniqueIdentifier);
|
2015-02-17 19:17:39 +00:00
|
|
|
trackIfUnresolved(RetTy);
|
2014-05-06 03:41:57 +00:00
|
|
|
return RetTy;
|
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DICompositeType *DIBuilder::createReplaceableCompositeType(
|
|
|
|
unsigned Tag, StringRef Name, DIScope *Scope, DIFile *F, unsigned Line,
|
2016-10-18 14:31:22 +00:00
|
|
|
unsigned RuntimeLang, uint64_t SizeInBits, uint32_t AlignInBits,
|
[llvm][DebugInfo] Add new DW_AT_APPLE_enum_kind to encode enum_extensibility (#124752)
When creating `EnumDecl`s from DWARF for Objective-C `NS_ENUM`s, the
Swift compiler tries to figure out if it should perform "swiftification"
of that enum (which involves renaming the enumerator cases, etc.). The
heuristics by which it determines whether we want to swiftify an enum is
by checking the `enum_extensibility` attribute (because that's what
`NS_ENUM` pretty much are). Currently LLDB fails to attach the
`EnumExtensibilityAttr` to `EnumDecl`s it creates (because there's not
enough info in DWARF to derive it), which means we have to fall back to
re-building Swift modules on-the-fly, slowing down expression evaluation
substantially. This happens around
https://github.com/swiftlang/swift/blob/4b3931c8ce437b3f13f245e6423f95c94a5876ac/lib/ClangImporter/ImportEnumInfo.cpp#L37-L59
To speed up Swift exression evaluation, this patch proposes encoding the
C/C++/Objective-C `enum_extensibility` attribute in DWARF via a new
`DW_AT_APPLE_ENUM_KIND`. This would currently be only used from the LLDB
Swift plugin. But may be of interest to other language plugins as well
(though I haven't come up with a concrete use-case for it outside of
Swift).
I'm open to naming suggestions of the various new attributes/attribute
constants proposed here. I tried to be as generic as possible if we
wanted to extend it to other kinds of enum properties (e.g., flag
enums).
The new attribute would look as follows:
```
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Closed)
DW_AT_name ("ClosedEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (23)
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Open)
DW_AT_name ("OpenEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (27)
```
Absence of the attribute means the extensibility of the enum is unknown
and abides by whatever the language rules of that CU dictate.
This does feel like a big hammer for quite a specific use-case, so I'm
happy to discuss alternatives.
Alternatives considered:
* Re-using an existing DWARF attribute to express extensibility. E.g., a
`DW_TAG_enumeration_type` could have a `DW_AT_count` or
`DW_AT_upper_bound` indicating the number of enumerators, which could
imply closed-ness. I felt like a dedicated attribute (which could be
generalized further) seemed more applicable. But I'm open to re-using
existing attributes.
* Encoding the entire attribute string (i.e., `DW_TAG_LLVM_annotation
("enum_extensibility((open))")`) on the `DW_TAG_enumeration_type`. Then
in LLDB somehow parse that out into a `EnumExtensibilityAttr`. I haven't
found a great API in Clang to parse arbitrary strings into AST nodes
(the ones I've found required fully formed C++ constructs). Though if
someone knows of a good way to do this, happy to consider that too.
2025-02-06 08:58:35 +00:00
|
|
|
DINode::DIFlags Flags, StringRef UniqueIdentifier, DINodeArray Annotations,
|
|
|
|
std::optional<uint32_t> EnumKind) {
|
2016-04-23 21:08:00 +00:00
|
|
|
auto *RetTy =
|
|
|
|
DICompositeType::getTemporary(
|
|
|
|
VMContext, Tag, Name, F, Line, getNonCompileUnitScope(Scope), nullptr,
|
[llvm][DebugInfo] Add new DW_AT_APPLE_enum_kind to encode enum_extensibility (#124752)
When creating `EnumDecl`s from DWARF for Objective-C `NS_ENUM`s, the
Swift compiler tries to figure out if it should perform "swiftification"
of that enum (which involves renaming the enumerator cases, etc.). The
heuristics by which it determines whether we want to swiftify an enum is
by checking the `enum_extensibility` attribute (because that's what
`NS_ENUM` pretty much are). Currently LLDB fails to attach the
`EnumExtensibilityAttr` to `EnumDecl`s it creates (because there's not
enough info in DWARF to derive it), which means we have to fall back to
re-building Swift modules on-the-fly, slowing down expression evaluation
substantially. This happens around
https://github.com/swiftlang/swift/blob/4b3931c8ce437b3f13f245e6423f95c94a5876ac/lib/ClangImporter/ImportEnumInfo.cpp#L37-L59
To speed up Swift exression evaluation, this patch proposes encoding the
C/C++/Objective-C `enum_extensibility` attribute in DWARF via a new
`DW_AT_APPLE_ENUM_KIND`. This would currently be only used from the LLDB
Swift plugin. But may be of interest to other language plugins as well
(though I haven't come up with a concrete use-case for it outside of
Swift).
I'm open to naming suggestions of the various new attributes/attribute
constants proposed here. I tried to be as generic as possible if we
wanted to extend it to other kinds of enum properties (e.g., flag
enums).
The new attribute would look as follows:
```
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Closed)
DW_AT_name ("ClosedEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (23)
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Open)
DW_AT_name ("OpenEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (27)
```
Absence of the attribute means the extensibility of the enum is unknown
and abides by whatever the language rules of that CU dictate.
This does feel like a big hammer for quite a specific use-case, so I'm
happy to discuss alternatives.
Alternatives considered:
* Re-using an existing DWARF attribute to express extensibility. E.g., a
`DW_TAG_enumeration_type` could have a `DW_AT_count` or
`DW_AT_upper_bound` indicating the number of enumerators, which could
imply closed-ness. I felt like a dedicated attribute (which could be
generalized further) seemed more applicable. But I'm open to re-using
existing attributes.
* Encoding the entire attribute string (i.e., `DW_TAG_LLVM_annotation
("enum_extensibility((open))")`) on the `DW_TAG_enumeration_type`. Then
in LLDB somehow parse that out into a `EnumExtensibilityAttr`. I haven't
found a great API in Clang to parse arbitrary strings into AST nodes
(the ones I've found required fully formed C++ constructs). Though if
someone knows of a good way to do this, happy to consider that too.
2025-02-06 08:58:35 +00:00
|
|
|
SizeInBits, AlignInBits, 0, Flags, nullptr, RuntimeLang, EnumKind,
|
|
|
|
nullptr, nullptr, UniqueIdentifier, nullptr, nullptr, nullptr,
|
|
|
|
nullptr, nullptr, Annotations)
|
2016-04-23 21:08:00 +00:00
|
|
|
.release();
|
2015-02-17 19:17:39 +00:00
|
|
|
trackIfUnresolved(RetTy);
|
2013-07-02 18:37:35 +00:00
|
|
|
return RetTy;
|
2012-02-08 00:22:26 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DINodeArray DIBuilder::getOrCreateArray(ArrayRef<Metadata *> Elements) {
|
2015-04-16 16:36:23 +00:00
|
|
|
return MDTuple::get(VMContext, Elements);
|
2010-12-07 23:25:47 +00:00
|
|
|
}
|
|
|
|
|
2017-01-12 15:49:46 +00:00
|
|
|
DIMacroNodeArray
|
|
|
|
DIBuilder::getOrCreateMacroArray(ArrayRef<Metadata *> Elements) {
|
|
|
|
return MDTuple::get(VMContext, Elements);
|
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DITypeRefArray DIBuilder::getOrCreateTypeArray(ArrayRef<Metadata *> Elements) {
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-09 18:38:53 +00:00
|
|
|
SmallVector<llvm::Metadata *, 16> Elts;
|
2021-12-08 20:35:39 -08:00
|
|
|
for (Metadata *E : Elements) {
|
|
|
|
if (isa_and_nonnull<MDNode>(E))
|
|
|
|
Elts.push_back(cast<DIType>(E));
|
2014-07-28 19:33:20 +00:00
|
|
|
else
|
2021-12-08 20:35:39 -08:00
|
|
|
Elts.push_back(E);
|
2014-07-28 19:33:20 +00:00
|
|
|
}
|
2015-04-29 16:38:44 +00:00
|
|
|
return DITypeRefArray(MDNode::get(VMContext, Elts));
|
2014-07-28 19:33:20 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DISubrange *DIBuilder::getOrCreateSubrange(int64_t Lo, int64_t Count) {
|
2020-05-28 13:31:22 +05:30
|
|
|
auto *LB = ConstantAsMetadata::get(
|
|
|
|
ConstantInt::getSigned(Type::getInt64Ty(VMContext), Lo));
|
|
|
|
auto *CountNode = ConstantAsMetadata::get(
|
|
|
|
ConstantInt::getSigned(Type::getInt64Ty(VMContext), Count));
|
|
|
|
return DISubrange::get(VMContext, CountNode, LB, nullptr, nullptr);
|
2010-12-08 01:50:15 +00:00
|
|
|
}
|
|
|
|
|
[Metadata] Extend 'count' field of DISubrange to take a metadata node
Summary:
This patch extends the DISubrange 'count' field to take either a
(signed) constant integer value or a reference to a DILocalVariable
or DIGlobalVariable.
This is patch [1/3] in a series to extend LLVM's DISubrange Metadata
node to support debugging of C99 variable length arrays and vectors with
runtime length like the Scalable Vector Extension for AArch64. It is
also a first step towards representing more complex cases like arrays
in Fortran.
Reviewers: echristo, pcc, aprantl, dexonsmith, clayborg, kristof.beyls, dblaikie
Reviewed By: aprantl
Subscribers: rnk, probinson, fhahn, aemerson, rengolin, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D41695
llvm-svn: 323313
2018-01-24 09:56:07 +00:00
|
|
|
DISubrange *DIBuilder::getOrCreateSubrange(int64_t Lo, Metadata *CountNode) {
|
2020-05-28 13:31:22 +05:30
|
|
|
auto *LB = ConstantAsMetadata::get(
|
|
|
|
ConstantInt::getSigned(Type::getInt64Ty(VMContext), Lo));
|
|
|
|
return DISubrange::get(VMContext, CountNode, LB, nullptr, nullptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
DISubrange *DIBuilder::getOrCreateSubrange(Metadata *CountNode, Metadata *LB,
|
|
|
|
Metadata *UB, Metadata *Stride) {
|
|
|
|
return DISubrange::get(VMContext, CountNode, LB, UB, Stride);
|
[Metadata] Extend 'count' field of DISubrange to take a metadata node
Summary:
This patch extends the DISubrange 'count' field to take either a
(signed) constant integer value or a reference to a DILocalVariable
or DIGlobalVariable.
This is patch [1/3] in a series to extend LLVM's DISubrange Metadata
node to support debugging of C99 variable length arrays and vectors with
runtime length like the Scalable Vector Extension for AArch64. It is
also a first step towards representing more complex cases like arrays
in Fortran.
Reviewers: echristo, pcc, aprantl, dexonsmith, clayborg, kristof.beyls, dblaikie
Reviewed By: aprantl
Subscribers: rnk, probinson, fhahn, aemerson, rengolin, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D41695
llvm-svn: 323313
2018-01-24 09:56:07 +00:00
|
|
|
}
|
|
|
|
|
2020-10-28 19:54:39 +05:30
|
|
|
DIGenericSubrange *DIBuilder::getOrCreateGenericSubrange(
|
|
|
|
DIGenericSubrange::BoundType CountNode, DIGenericSubrange::BoundType LB,
|
|
|
|
DIGenericSubrange::BoundType UB, DIGenericSubrange::BoundType Stride) {
|
|
|
|
auto ConvToMetadata = [&](DIGenericSubrange::BoundType Bound) -> Metadata * {
|
2023-04-15 21:16:16 -05:00
|
|
|
return isa<DIExpression *>(Bound) ? (Metadata *)cast<DIExpression *>(Bound)
|
|
|
|
: (Metadata *)cast<DIVariable *>(Bound);
|
2020-10-28 19:54:39 +05:30
|
|
|
};
|
|
|
|
return DIGenericSubrange::get(VMContext, ConvToMetadata(CountNode),
|
|
|
|
ConvToMetadata(LB), ConvToMetadata(UB),
|
|
|
|
ConvToMetadata(Stride));
|
|
|
|
}
|
|
|
|
|
2025-02-24 11:11:53 -07:00
|
|
|
DISubrangeType *DIBuilder::createSubrangeType(
|
|
|
|
StringRef Name, DIFile *File, unsigned LineNo, DIScope *Scope,
|
|
|
|
uint64_t SizeInBits, uint32_t AlignInBits, DINode::DIFlags Flags,
|
|
|
|
DIType *Ty, Metadata *LowerBound, Metadata *UpperBound, Metadata *Stride,
|
|
|
|
Metadata *Bias) {
|
|
|
|
return DISubrangeType::get(VMContext, Name, File, LineNo, Scope, SizeInBits,
|
|
|
|
AlignInBits, Flags, Ty, LowerBound, UpperBound,
|
|
|
|
Stride, Bias);
|
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
static void checkGlobalVariableScope(DIScope *Context) {
|
2015-04-06 23:34:41 +00:00
|
|
|
#ifndef NDEBUG
|
2015-04-16 01:01:28 +00:00
|
|
|
if (auto *CT =
|
2015-04-29 16:38:44 +00:00
|
|
|
dyn_cast_or_null<DICompositeType>(getNonCompileUnitScope(Context)))
|
2015-04-16 01:01:28 +00:00
|
|
|
assert(CT->getIdentifier().empty() &&
|
2014-11-21 19:47:48 +00:00
|
|
|
"Context of a global variable should not be a type with identifier");
|
2015-04-06 23:34:41 +00:00
|
|
|
#endif
|
2014-09-17 09:28:34 +00:00
|
|
|
}
|
|
|
|
|
2016-12-20 02:09:43 +00:00
|
|
|
DIGlobalVariableExpression *DIBuilder::createGlobalVariableExpression(
|
2015-04-29 16:38:44 +00:00
|
|
|
DIScope *Context, StringRef Name, StringRef LinkageName, DIFile *F,
|
2021-11-11 13:39:50 -08:00
|
|
|
unsigned LineNumber, DIType *Ty, bool IsLocalToUnit, bool isDefined,
|
|
|
|
DIExpression *Expr, MDNode *Decl, MDTuple *TemplateParams,
|
|
|
|
uint32_t AlignInBits, DINodeArray Annotations) {
|
2015-03-03 17:24:31 +00:00
|
|
|
checkGlobalVariableScope(Context);
|
|
|
|
|
2016-12-20 02:09:43 +00:00
|
|
|
auto *GV = DIGlobalVariable::getDistinct(
|
2016-04-23 22:29:09 +00:00
|
|
|
VMContext, cast_or_null<DIScope>(Context), Name, LinkageName, F,
|
2021-11-11 13:39:50 -08:00
|
|
|
LineNumber, Ty, IsLocalToUnit, isDefined,
|
|
|
|
cast_or_null<DIDerivedType>(Decl), TemplateParams, AlignInBits,
|
|
|
|
Annotations);
|
2017-08-30 18:06:51 +00:00
|
|
|
if (!Expr)
|
|
|
|
Expr = createExpression();
|
2016-12-20 02:09:43 +00:00
|
|
|
auto *N = DIGlobalVariableExpression::get(VMContext, GV, Expr);
|
2015-03-03 17:24:31 +00:00
|
|
|
AllGVs.push_back(N);
|
|
|
|
return N;
|
2014-09-17 09:28:34 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DIGlobalVariable *DIBuilder::createTempGlobalVariableFwdDecl(
|
|
|
|
DIScope *Context, StringRef Name, StringRef LinkageName, DIFile *F,
|
2019-12-23 07:27:05 +00:00
|
|
|
unsigned LineNumber, DIType *Ty, bool IsLocalToUnit, MDNode *Decl,
|
|
|
|
MDTuple *TemplateParams, uint32_t AlignInBits) {
|
2015-03-03 17:24:31 +00:00
|
|
|
checkGlobalVariableScope(Context);
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
return DIGlobalVariable::getTemporary(
|
|
|
|
VMContext, cast_or_null<DIScope>(Context), Name, LinkageName, F,
|
2019-12-23 07:27:05 +00:00
|
|
|
LineNumber, Ty, IsLocalToUnit, false,
|
2021-07-19 09:33:55 -07:00
|
|
|
cast_or_null<DIDerivedType>(Decl), TemplateParams, AlignInBits,
|
|
|
|
nullptr)
|
2015-04-16 01:37:00 +00:00
|
|
|
.release();
|
2010-12-07 23:25:47 +00:00
|
|
|
}
|
|
|
|
|
2015-07-31 17:55:53 +00:00
|
|
|
static DILocalVariable *createLocalVariable(
|
|
|
|
LLVMContext &VMContext,
|
2023-06-12 16:01:18 +02:00
|
|
|
SmallVectorImpl<TrackingMDNodeRef> &PreservedNodes,
|
|
|
|
DIScope *Context, StringRef Name, unsigned ArgNo, DIFile *File,
|
2016-10-20 00:13:12 +00:00
|
|
|
unsigned LineNo, DIType *Ty, bool AlwaysPreserve, DINode::DIFlags Flags,
|
2021-07-19 09:11:10 -07:00
|
|
|
uint32_t AlignInBits, DINodeArray Annotations = nullptr) {
|
2015-07-10 23:26:02 +00:00
|
|
|
// FIXME: Why doesn't this check for a subprogram or lexical block (AFAICT
|
2015-03-03 17:24:31 +00:00
|
|
|
// the only valid scopes)?
|
2023-06-12 16:01:18 +02:00
|
|
|
auto *Scope = cast<DILocalScope>(Context);
|
|
|
|
auto *Node = DILocalVariable::get(VMContext, Scope, Name, File, LineNo, Ty,
|
|
|
|
ArgNo, Flags, AlignInBits, Annotations);
|
2010-12-07 23:58:00 +00:00
|
|
|
if (AlwaysPreserve) {
|
2015-07-10 23:26:02 +00:00
|
|
|
// The optimizer may remove local variables. If there is an interest
|
2010-12-07 23:58:00 +00:00
|
|
|
// to preserve variable info in such situation then stash it in a
|
|
|
|
// named mdnode.
|
2023-06-12 16:01:18 +02:00
|
|
|
PreservedNodes.emplace_back(Node);
|
2010-12-07 23:58:00 +00:00
|
|
|
}
|
2015-03-03 17:24:31 +00:00
|
|
|
return Node;
|
2010-12-07 23:58:00 +00:00
|
|
|
}
|
|
|
|
|
2015-07-31 17:55:53 +00:00
|
|
|
DILocalVariable *DIBuilder::createAutoVariable(DIScope *Scope, StringRef Name,
|
|
|
|
DIFile *File, unsigned LineNo,
|
|
|
|
DIType *Ty, bool AlwaysPreserve,
|
2016-10-20 00:13:12 +00:00
|
|
|
DINode::DIFlags Flags,
|
|
|
|
uint32_t AlignInBits) {
|
2023-06-12 16:01:18 +02:00
|
|
|
assert(Scope && isa<DILocalScope>(Scope) &&
|
|
|
|
"Unexpected scope for a local variable.");
|
|
|
|
return createLocalVariable(
|
|
|
|
VMContext, getSubprogramNodesTrackingVector(Scope), Scope, Name,
|
|
|
|
/* ArgNo */ 0, File, LineNo, Ty, AlwaysPreserve, Flags, AlignInBits);
|
2015-07-31 17:55:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DILocalVariable *DIBuilder::createParameterVariable(
|
|
|
|
DIScope *Scope, StringRef Name, unsigned ArgNo, DIFile *File,
|
2021-07-19 09:11:10 -07:00
|
|
|
unsigned LineNo, DIType *Ty, bool AlwaysPreserve, DINode::DIFlags Flags,
|
|
|
|
DINodeArray Annotations) {
|
2015-07-31 17:55:53 +00:00
|
|
|
assert(ArgNo && "Expected non-zero argument number for parameter");
|
2023-06-12 16:01:18 +02:00
|
|
|
assert(Scope && isa<DILocalScope>(Scope) &&
|
|
|
|
"Unexpected scope for a local variable.");
|
|
|
|
return createLocalVariable(
|
|
|
|
VMContext, getSubprogramNodesTrackingVector(Scope), Scope, Name, ArgNo,
|
|
|
|
File, LineNo, Ty, AlwaysPreserve, Flags, /*AlignInBits=*/0, Annotations);
|
2015-07-31 17:55:53 +00:00
|
|
|
}
|
|
|
|
|
2023-06-12 16:01:18 +02:00
|
|
|
DILabel *DIBuilder::createLabel(DIScope *Context, StringRef Name, DIFile *File,
|
|
|
|
unsigned LineNo, bool AlwaysPreserve) {
|
|
|
|
auto *Scope = cast<DILocalScope>(Context);
|
|
|
|
auto *Node = DILabel::get(VMContext, Scope, Name, File, LineNo);
|
[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.
In order to set breakpoints on labels and list source code around
labels, we need collect debug information for labels, i.e., label
name, the function label belong, line number in the file, and the
address label located. In order to keep these information in LLVM
IR and to allow backend to generate debug information correctly.
We create a new kind of metadata for labels, DILabel. The format
of DILabel is
!DILabel(scope: !1, name: "foo", file: !2, line: 3)
We hope to keep debug information as much as possible even the
code is optimized. So, we create a new kind of intrinsic for label
metadata to avoid the metadata is eliminated with basic block.
The intrinsic will keep existing if we keep it from optimized out.
The format of the intrinsic is
llvm.dbg.label(metadata !1)
It has only one argument, that is the DILabel metadata. The
intrinsic will follow the label immediately. Backend could get the
label metadata through the intrinsic's parameter.
We also create DIBuilder API for labels to be used by Frontend.
Frontend could use createLabel() to allocate DILabel objects, and use
insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.
Differential Revision: https://reviews.llvm.org/D45024
Patch by Hsiangkai Wang.
llvm-svn: 331841
2018-05-09 02:40:45 +00:00
|
|
|
|
|
|
|
if (AlwaysPreserve) {
|
|
|
|
/// The optimizer may remove labels. If there is an interest
|
|
|
|
/// to preserve label info in such situation then append it to
|
|
|
|
/// the list of retained nodes of the DISubprogram.
|
2023-06-12 16:01:18 +02:00
|
|
|
getSubprogramNodesTrackingVector(Scope).emplace_back(Node);
|
[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.
In order to set breakpoints on labels and list source code around
labels, we need collect debug information for labels, i.e., label
name, the function label belong, line number in the file, and the
address label located. In order to keep these information in LLVM
IR and to allow backend to generate debug information correctly.
We create a new kind of metadata for labels, DILabel. The format
of DILabel is
!DILabel(scope: !1, name: "foo", file: !2, line: 3)
We hope to keep debug information as much as possible even the
code is optimized. So, we create a new kind of intrinsic for label
metadata to avoid the metadata is eliminated with basic block.
The intrinsic will keep existing if we keep it from optimized out.
The format of the intrinsic is
llvm.dbg.label(metadata !1)
It has only one argument, that is the DILabel metadata. The
intrinsic will follow the label immediately. Backend could get the
label metadata through the intrinsic's parameter.
We also create DIBuilder API for labels to be used by Frontend.
Frontend could use createLabel() to allocate DILabel objects, and use
insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.
Differential Revision: https://reviews.llvm.org/D45024
Patch by Hsiangkai Wang.
llvm-svn: 331841
2018-05-09 02:40:45 +00:00
|
|
|
}
|
|
|
|
return Node;
|
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DIExpression *DIBuilder::createExpression(ArrayRef<uint64_t> Addr) {
|
|
|
|
return DIExpression::get(VMContext, Addr);
|
2010-12-07 23:25:47 +00:00
|
|
|
}
|
|
|
|
|
2015-08-26 22:50:16 +00:00
|
|
|
template <class... Ts>
|
2021-11-11 13:39:50 -08:00
|
|
|
static DISubprogram *getSubprogram(bool IsDistinct, Ts &&...Args) {
|
2015-08-26 22:50:16 +00:00
|
|
|
if (IsDistinct)
|
|
|
|
return DISubprogram::getDistinct(std::forward<Ts>(Args)...);
|
|
|
|
return DISubprogram::get(std::forward<Ts>(Args)...);
|
|
|
|
}
|
|
|
|
|
2015-11-05 22:03:56 +00:00
|
|
|
DISubprogram *DIBuilder::createFunction(
|
|
|
|
DIScope *Context, StringRef Name, StringRef LinkageName, DIFile *File,
|
2018-11-19 18:29:28 +00:00
|
|
|
unsigned LineNo, DISubroutineType *Ty, unsigned ScopeLine,
|
|
|
|
DINode::DIFlags Flags, DISubprogram::DISPFlags SPFlags,
|
|
|
|
DITemplateParameterArray TParams, DISubprogram *Decl,
|
2022-04-06 08:22:49 -04:00
|
|
|
DITypeArray ThrownTypes, DINodeArray Annotations,
|
|
|
|
StringRef TargetFuncName) {
|
2018-11-19 18:29:28 +00:00
|
|
|
bool IsDefinition = SPFlags & DISubprogram::SPFlagDefinition;
|
2016-04-15 15:57:41 +00:00
|
|
|
auto *Node = getSubprogram(
|
2018-11-19 18:29:28 +00:00
|
|
|
/*IsDistinct=*/IsDefinition, VMContext, getNonCompileUnitScope(Context),
|
|
|
|
Name, LinkageName, File, LineNo, Ty, ScopeLine, nullptr, 0, 0, Flags,
|
2023-06-12 16:01:18 +02:00
|
|
|
SPFlags, IsDefinition ? CUNode : nullptr, TParams, Decl, nullptr,
|
|
|
|
ThrownTypes, Annotations, TargetFuncName);
|
2015-03-03 17:24:31 +00:00
|
|
|
|
2018-11-19 18:29:28 +00:00
|
|
|
if (IsDefinition)
|
2015-03-03 17:24:31 +00:00
|
|
|
AllSubprograms.push_back(Node);
|
|
|
|
trackIfUnresolved(Node);
|
|
|
|
return Node;
|
2014-09-17 09:28:34 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DISubprogram *DIBuilder::createTempFunctionFwdDecl(
|
|
|
|
DIScope *Context, StringRef Name, StringRef LinkageName, DIFile *File,
|
2018-11-19 18:29:28 +00:00
|
|
|
unsigned LineNo, DISubroutineType *Ty, unsigned ScopeLine,
|
|
|
|
DINode::DIFlags Flags, DISubprogram::DISPFlags SPFlags,
|
|
|
|
DITemplateParameterArray TParams, DISubprogram *Decl,
|
2017-04-26 22:56:44 +00:00
|
|
|
DITypeArray ThrownTypes) {
|
2018-11-19 18:29:28 +00:00
|
|
|
bool IsDefinition = SPFlags & DISubprogram::SPFlagDefinition;
|
|
|
|
return DISubprogram::getTemporary(VMContext, getNonCompileUnitScope(Context),
|
|
|
|
Name, LinkageName, File, LineNo, Ty,
|
|
|
|
ScopeLine, nullptr, 0, 0, Flags, SPFlags,
|
|
|
|
IsDefinition ? CUNode : nullptr, TParams,
|
|
|
|
Decl, nullptr, ThrownTypes)
|
2015-04-29 16:38:44 +00:00
|
|
|
.release();
|
|
|
|
}
|
|
|
|
|
2017-04-26 22:56:44 +00:00
|
|
|
DISubprogram *DIBuilder::createMethod(
|
|
|
|
DIScope *Context, StringRef Name, StringRef LinkageName, DIFile *F,
|
2018-11-19 18:29:28 +00:00
|
|
|
unsigned LineNo, DISubroutineType *Ty, unsigned VIndex, int ThisAdjustment,
|
|
|
|
DIType *VTableHolder, DINode::DIFlags Flags,
|
|
|
|
DISubprogram::DISPFlags SPFlags, DITemplateParameterArray TParams,
|
|
|
|
DITypeArray ThrownTypes) {
|
2013-10-15 23:31:36 +00:00
|
|
|
assert(getNonCompileUnitScope(Context) &&
|
|
|
|
"Methods should have both a Context and a context that isn't "
|
|
|
|
"the compile unit.");
|
2015-03-03 17:24:31 +00:00
|
|
|
// FIXME: Do we want to use different scope/lines?
|
2018-11-19 18:29:28 +00:00
|
|
|
bool IsDefinition = SPFlags & DISubprogram::SPFlagDefinition;
|
2015-11-05 22:03:56 +00:00
|
|
|
auto *SP = getSubprogram(
|
2018-11-19 18:29:28 +00:00
|
|
|
/*IsDistinct=*/IsDefinition, VMContext, cast<DIScope>(Context), Name,
|
|
|
|
LinkageName, F, LineNo, Ty, LineNo, VTableHolder, VIndex, ThisAdjustment,
|
|
|
|
Flags, SPFlags, IsDefinition ? CUNode : nullptr, TParams, nullptr,
|
|
|
|
nullptr, ThrownTypes);
|
2015-03-03 17:24:31 +00:00
|
|
|
|
2018-11-19 18:29:28 +00:00
|
|
|
if (IsDefinition)
|
2015-04-06 23:18:49 +00:00
|
|
|
AllSubprograms.push_back(SP);
|
|
|
|
trackIfUnresolved(SP);
|
|
|
|
return SP;
|
2010-12-08 20:42:44 +00:00
|
|
|
}
|
|
|
|
|
2021-11-11 13:39:50 -08:00
|
|
|
DICommonBlock *DIBuilder::createCommonBlock(DIScope *Scope,
|
|
|
|
DIGlobalVariable *Decl,
|
|
|
|
StringRef Name, DIFile *File,
|
|
|
|
unsigned LineNo) {
|
|
|
|
return DICommonBlock::get(VMContext, Scope, Decl, Name, File, LineNo);
|
Add LLVM IR debug info support for Fortran COMMON blocks
COMMON blocks are a feature of Fortran that has no direct analog in C languages, but they are similar to data sections in assembly language programming. A COMMON block is a named area of memory that holds a collection of variables. Fortran subprograms may map the COMMON block memory area to their own, possibly distinct, non-empty list of variables. A Fortran COMMON block might look like the following example.
COMMON /ALPHA/ I, J
For this construct, the compiler generates a new scope-like DI construct (!DICommonBlock) into which variables (see I, J above) can be placed. As the common block implies a range of storage with global lifetime, the !DICommonBlock refers to a !DIGlobalVariable. The Fortran variable that comprise the COMMON block are also linked via metadata to offsets within the global variable that stands for the entire common block.
@alpha_ = common global %alphabytes_ zeroinitializer, align 64, !dbg !27, !dbg !30, !dbg !33
!14 = distinct !DISubprogram(…)
!20 = distinct !DICommonBlock(scope: !14, declaration: !25, name: "alpha")
!25 = distinct !DIGlobalVariable(scope: !20, name: "common alpha", type: !24)
!27 = !DIGlobalVariableExpression(var: !25, expr: !DIExpression())
!29 = distinct !DIGlobalVariable(scope: !20, name: "i", file: !3, type: !28)
!30 = !DIGlobalVariableExpression(var: !29, expr: !DIExpression())
!31 = distinct !DIGlobalVariable(scope: !20, name: "j", file: !3, type: !28)
!32 = !DIExpression(DW_OP_plus_uconst, 4)
!33 = !DIGlobalVariableExpression(var: !31, expr: !32)
The DWARF generated for this is as follows.
DW_TAG_common_block:
DW_AT_name: alpha
DW_AT_location: @alpha_+0
DW_TAG_variable:
DW_AT_name: common alpha
DW_AT_type: array of 8 bytes
DW_AT_location: @alpha_+0
DW_TAG_variable:
DW_AT_name: i
DW_AT_type: integer*4
DW_AT_location: @Alpha+0
DW_TAG_variable:
DW_AT_name: j
DW_AT_type: integer*4
DW_AT_location: @Alpha+4
Patch by Eric Schweitz!
Differential Revision: https://reviews.llvm.org/D54327
llvm-svn: 357934
2019-04-08 19:13:55 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DINamespace *DIBuilder::createNameSpace(DIScope *Scope, StringRef Name,
|
2016-11-03 19:42:02 +00:00
|
|
|
bool ExportSymbols) {
|
2017-04-28 22:25:46 +00:00
|
|
|
|
|
|
|
// It is okay to *not* make anonymous top-level namespaces distinct, because
|
|
|
|
// all nodes that have an anonymous namespace as their parent scope are
|
|
|
|
// guaranteed to be unique and/or are linked to their containing
|
|
|
|
// DICompileUnit. This decision is an explicit tradeoff of link time versus
|
|
|
|
// memory usage versus code simplicity and may get revisited in the future.
|
|
|
|
return DINamespace::get(VMContext, getNonCompileUnitScope(Scope), Name,
|
|
|
|
ExportSymbols);
|
2010-12-07 23:25:47 +00:00
|
|
|
}
|
|
|
|
|
2015-06-29 23:03:47 +00:00
|
|
|
DIModule *DIBuilder::createModule(DIScope *Scope, StringRef Name,
|
|
|
|
StringRef ConfigurationMacros,
|
2020-05-08 11:31:41 +05:30
|
|
|
StringRef IncludePath, StringRef APINotesFile,
|
2020-12-17 11:08:46 -05:00
|
|
|
DIFile *File, unsigned LineNo, bool IsDecl) {
|
2020-05-08 11:31:41 +05:30
|
|
|
return DIModule::get(VMContext, File, getNonCompileUnitScope(Scope), Name,
|
2020-12-17 11:08:46 -05:00
|
|
|
ConfigurationMacros, IncludePath, APINotesFile, LineNo,
|
|
|
|
IsDecl);
|
2015-06-29 23:03:47 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DILexicalBlockFile *DIBuilder::createLexicalBlockFile(DIScope *Scope,
|
|
|
|
DIFile *File,
|
|
|
|
unsigned Discriminator) {
|
|
|
|
return DILexicalBlockFile::get(VMContext, Scope, File, Discriminator);
|
2011-10-11 22:59:11 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
DILexicalBlock *DIBuilder::createLexicalBlock(DIScope *Scope, DIFile *File,
|
|
|
|
unsigned Line, unsigned Col) {
|
2015-03-03 17:24:31 +00:00
|
|
|
// Make these distinct, to avoid merging two lexical blocks on the same
|
|
|
|
// file/line/column.
|
2015-04-29 16:38:44 +00:00
|
|
|
return DILexicalBlock::getDistinct(VMContext, getNonCompileUnitScope(Scope),
|
2015-04-15 23:19:27 +00:00
|
|
|
File, Line, Col);
|
2010-12-08 01:50:15 +00:00
|
|
|
}
|
|
|
|
|
2025-02-12 17:50:39 +00:00
|
|
|
DbgInstPtr DIBuilder::insertDeclare(Value *Storage, DILocalVariable *VarInfo,
|
|
|
|
DIExpression *Expr, const DILocation *DL,
|
|
|
|
BasicBlock *InsertAtEnd) {
|
|
|
|
// If this block already has a terminator then insert this intrinsic before
|
|
|
|
// the terminator. Otherwise, put it at the end of the block.
|
|
|
|
Instruction *InsertBefore = InsertAtEnd->getTerminator();
|
2025-02-13 10:46:42 +00:00
|
|
|
return insertDeclare(Storage, VarInfo, Expr, DL,
|
|
|
|
InsertBefore ? InsertBefore->getIterator()
|
|
|
|
: InsertAtEnd->end());
|
2025-02-12 17:50:39 +00:00
|
|
|
}
|
|
|
|
|
2024-03-12 10:25:58 +00:00
|
|
|
DbgInstPtr DIBuilder::insertDbgAssign(Instruction *LinkedInstr, Value *Val,
|
|
|
|
DILocalVariable *SrcVar,
|
|
|
|
DIExpression *ValExpr, Value *Addr,
|
|
|
|
DIExpression *AddrExpr,
|
|
|
|
const DILocation *DL) {
|
|
|
|
auto *Link = cast_or_null<DIAssignID>(
|
|
|
|
LinkedInstr->getMetadata(LLVMContext::MD_DIAssignID));
|
|
|
|
assert(Link && "Linked instruction must have DIAssign metadata attached");
|
|
|
|
|
|
|
|
if (M.IsNewDbgInfoFormat) {
|
[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)
This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which reflects
the updated terminology for the "final" implementation of the RemoveDI
feature. This is a pure string substitution + clang-format patch. The
only manual component of this patch was determining where to perform
these string substitutions: `DPValue` and `DPV` are almost exclusively
used for DbgRecords, *except* for:
- llvm/lib/target, where 'DP' is used to mean double-precision, and so
appears as part of .td files and in variable names. NB: There is a
single existing use of `DPValue` here that refers to debug info, which
I've manually updated.
- llvm/tools/gold, where 'LDPV' is used as a prefix for symbol
visibility enums.
Outside of these places, I've applied several basic string
substitutions, with the intent that they only affect DbgRecord-related
identifiers; I've checked them as I went through to verify this, with
reasonable confidence that there are no unintended changes that slipped
through the cracks. The substitutions applied are all case-sensitive,
and are applied in the order shown:
```
DPValue -> DbgVariableRecord
DPVal -> DbgVarRec
DPV -> DVR
```
Following the previous rename patches, it should be the case that there
are no instances of any of these strings that are meant to refer to the
general case of DbgRecords, or anything other than the DPValue class.
The idea behind this patch is therefore that pure string substitution is
correct in all cases as long as these assumptions hold.
2024-03-19 20:07:07 +00:00
|
|
|
DbgVariableRecord *DVR = DbgVariableRecord::createDVRAssign(
|
|
|
|
Val, SrcVar, ValExpr, Link, Addr, AddrExpr, DL);
|
2024-03-12 10:25:58 +00:00
|
|
|
// Insert after LinkedInstr.
|
|
|
|
BasicBlock::iterator NextIt = std::next(LinkedInstr->getIterator());
|
2025-02-13 10:46:42 +00:00
|
|
|
NextIt.setHeadBit(true);
|
|
|
|
insertDbgVariableRecord(DVR, NextIt);
|
[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)
This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which reflects
the updated terminology for the "final" implementation of the RemoveDI
feature. This is a pure string substitution + clang-format patch. The
only manual component of this patch was determining where to perform
these string substitutions: `DPValue` and `DPV` are almost exclusively
used for DbgRecords, *except* for:
- llvm/lib/target, where 'DP' is used to mean double-precision, and so
appears as part of .td files and in variable names. NB: There is a
single existing use of `DPValue` here that refers to debug info, which
I've manually updated.
- llvm/tools/gold, where 'LDPV' is used as a prefix for symbol
visibility enums.
Outside of these places, I've applied several basic string
substitutions, with the intent that they only affect DbgRecord-related
identifiers; I've checked them as I went through to verify this, with
reasonable confidence that there are no unintended changes that slipped
through the cracks. The substitutions applied are all case-sensitive,
and are applied in the order shown:
```
DPValue -> DbgVariableRecord
DPVal -> DbgVarRec
DPV -> DVR
```
Following the previous rename patches, it should be the case that there
are no instances of any of these strings that are meant to refer to the
general case of DbgRecords, or anything other than the DPValue class.
The idea behind this patch is therefore that pure string substitution is
correct in all cases as long as these assumptions hold.
2024-03-19 20:07:07 +00:00
|
|
|
return DVR;
|
2024-03-12 10:25:58 +00:00
|
|
|
}
|
|
|
|
|
2022-11-07 17:39:40 +00:00
|
|
|
LLVMContext &Ctx = LinkedInstr->getContext();
|
|
|
|
Module *M = LinkedInstr->getModule();
|
|
|
|
if (!AssignFn)
|
2024-10-11 05:26:03 -07:00
|
|
|
AssignFn = Intrinsic::getOrInsertDeclaration(M, Intrinsic::dbg_assign);
|
2022-11-07 17:39:40 +00:00
|
|
|
|
|
|
|
std::array<Value *, 6> Args = {
|
|
|
|
MetadataAsValue::get(Ctx, ValueAsMetadata::get(Val)),
|
|
|
|
MetadataAsValue::get(Ctx, SrcVar),
|
|
|
|
MetadataAsValue::get(Ctx, ValExpr),
|
|
|
|
MetadataAsValue::get(Ctx, Link),
|
|
|
|
MetadataAsValue::get(Ctx, ValueAsMetadata::get(Addr)),
|
|
|
|
MetadataAsValue::get(Ctx, AddrExpr),
|
|
|
|
};
|
|
|
|
|
|
|
|
IRBuilder<> B(Ctx);
|
|
|
|
B.SetCurrentDebugLocation(DL);
|
|
|
|
|
|
|
|
auto *DVI = cast<DbgAssignIntrinsic>(B.CreateCall(AssignFn, Args));
|
2025-01-24 10:53:11 +00:00
|
|
|
DVI->insertAfter(LinkedInstr->getIterator());
|
2022-11-07 17:39:40 +00:00
|
|
|
return DVI;
|
|
|
|
}
|
|
|
|
|
2020-02-16 17:46:26 +01:00
|
|
|
/// Initialize IRBuilder for inserting dbg.declare and dbg.value intrinsics.
|
|
|
|
/// This abstracts over the various ways to specify an insert position.
|
|
|
|
static void initIRBuilder(IRBuilder<> &Builder, const DILocation *DL,
|
2025-02-13 10:46:42 +00:00
|
|
|
InsertPosition InsertPt) {
|
|
|
|
Builder.SetInsertPoint(InsertPt.getBasicBlock(), InsertPt);
|
2020-02-16 17:46:26 +01:00
|
|
|
Builder.SetCurrentDebugLocation(DL);
|
2017-10-03 20:36:40 +00:00
|
|
|
}
|
|
|
|
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-09 18:38:53 +00:00
|
|
|
static Value *getDbgIntrinsicValueImpl(LLVMContext &VMContext, Value *V) {
|
|
|
|
assert(V && "no value passed to dbg intrinsic");
|
|
|
|
return MetadataAsValue::get(VMContext, ValueAsMetadata::get(V));
|
|
|
|
}
|
|
|
|
|
2017-09-21 19:52:03 +00:00
|
|
|
static Function *getDeclareIntrin(Module &M) {
|
2024-10-11 05:26:03 -07:00
|
|
|
return Intrinsic::getOrInsertDeclaration(&M, Intrinsic::dbg_declare);
|
2017-09-21 19:52:03 +00:00
|
|
|
}
|
|
|
|
|
2025-02-13 10:46:42 +00:00
|
|
|
DbgInstPtr DIBuilder::insertDbgValueIntrinsic(llvm::Value *Val,
|
|
|
|
DILocalVariable *VarInfo,
|
|
|
|
DIExpression *Expr,
|
|
|
|
const DILocation *DL,
|
|
|
|
InsertPosition InsertPt) {
|
2024-03-12 10:25:58 +00:00
|
|
|
if (M.IsNewDbgInfoFormat) {
|
[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)
This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which reflects
the updated terminology for the "final" implementation of the RemoveDI
feature. This is a pure string substitution + clang-format patch. The
only manual component of this patch was determining where to perform
these string substitutions: `DPValue` and `DPV` are almost exclusively
used for DbgRecords, *except* for:
- llvm/lib/target, where 'DP' is used to mean double-precision, and so
appears as part of .td files and in variable names. NB: There is a
single existing use of `DPValue` here that refers to debug info, which
I've manually updated.
- llvm/tools/gold, where 'LDPV' is used as a prefix for symbol
visibility enums.
Outside of these places, I've applied several basic string
substitutions, with the intent that they only affect DbgRecord-related
identifiers; I've checked them as I went through to verify this, with
reasonable confidence that there are no unintended changes that slipped
through the cracks. The substitutions applied are all case-sensitive,
and are applied in the order shown:
```
DPValue -> DbgVariableRecord
DPVal -> DbgVarRec
DPV -> DVR
```
Following the previous rename patches, it should be the case that there
are no instances of any of these strings that are meant to refer to the
general case of DbgRecords, or anything other than the DPValue class.
The idea behind this patch is therefore that pure string substitution is
correct in all cases as long as these assumptions hold.
2024-03-19 20:07:07 +00:00
|
|
|
DbgVariableRecord *DVR =
|
|
|
|
DbgVariableRecord::createDbgVariableRecord(Val, VarInfo, Expr, DL);
|
2025-02-13 10:46:42 +00:00
|
|
|
insertDbgVariableRecord(DVR, InsertPt);
|
[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)
This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which reflects
the updated terminology for the "final" implementation of the RemoveDI
feature. This is a pure string substitution + clang-format patch. The
only manual component of this patch was determining where to perform
these string substitutions: `DPValue` and `DPV` are almost exclusively
used for DbgRecords, *except* for:
- llvm/lib/target, where 'DP' is used to mean double-precision, and so
appears as part of .td files and in variable names. NB: There is a
single existing use of `DPValue` here that refers to debug info, which
I've manually updated.
- llvm/tools/gold, where 'LDPV' is used as a prefix for symbol
visibility enums.
Outside of these places, I've applied several basic string
substitutions, with the intent that they only affect DbgRecord-related
identifiers; I've checked them as I went through to verify this, with
reasonable confidence that there are no unintended changes that slipped
through the cracks. The substitutions applied are all case-sensitive,
and are applied in the order shown:
```
DPValue -> DbgVariableRecord
DPVal -> DbgVarRec
DPV -> DVR
```
Following the previous rename patches, it should be the case that there
are no instances of any of these strings that are meant to refer to the
general case of DbgRecords, or anything other than the DPValue class.
The idea behind this patch is therefore that pure string substitution is
correct in all cases as long as these assumptions hold.
2024-03-19 20:07:07 +00:00
|
|
|
return DVR;
|
2024-03-12 10:25:58 +00:00
|
|
|
}
|
|
|
|
|
2022-01-19 15:33:59 -08:00
|
|
|
if (!ValueFn)
|
2024-10-11 05:26:03 -07:00
|
|
|
ValueFn = Intrinsic::getOrInsertDeclaration(&M, Intrinsic::dbg_value);
|
2025-02-13 10:46:42 +00:00
|
|
|
auto *DVI = insertDbgIntrinsic(ValueFn, Val, VarInfo, Expr, DL, InsertPt);
|
|
|
|
cast<CallInst>(DVI)->setTailCall();
|
|
|
|
return DVI;
|
2022-01-19 15:33:59 -08:00
|
|
|
}
|
|
|
|
|
2024-03-12 10:25:58 +00:00
|
|
|
DbgInstPtr DIBuilder::insertDeclare(Value *Storage, DILocalVariable *VarInfo,
|
|
|
|
DIExpression *Expr, const DILocation *DL,
|
2025-02-13 10:46:42 +00:00
|
|
|
InsertPosition InsertPt) {
|
2015-04-29 16:38:44 +00:00
|
|
|
assert(VarInfo && "empty or invalid DILocalVariable* passed to dbg.declare");
|
2015-04-15 21:18:07 +00:00
|
|
|
assert(DL && "Expected debug loc");
|
|
|
|
assert(DL->getScope()->getSubprogram() ==
|
|
|
|
VarInfo->getScope()->getSubprogram() &&
|
|
|
|
"Expected matching subprograms");
|
2024-03-12 10:25:58 +00:00
|
|
|
|
|
|
|
if (M.IsNewDbgInfoFormat) {
|
[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)
This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which reflects
the updated terminology for the "final" implementation of the RemoveDI
feature. This is a pure string substitution + clang-format patch. The
only manual component of this patch was determining where to perform
these string substitutions: `DPValue` and `DPV` are almost exclusively
used for DbgRecords, *except* for:
- llvm/lib/target, where 'DP' is used to mean double-precision, and so
appears as part of .td files and in variable names. NB: There is a
single existing use of `DPValue` here that refers to debug info, which
I've manually updated.
- llvm/tools/gold, where 'LDPV' is used as a prefix for symbol
visibility enums.
Outside of these places, I've applied several basic string
substitutions, with the intent that they only affect DbgRecord-related
identifiers; I've checked them as I went through to verify this, with
reasonable confidence that there are no unintended changes that slipped
through the cracks. The substitutions applied are all case-sensitive,
and are applied in the order shown:
```
DPValue -> DbgVariableRecord
DPVal -> DbgVarRec
DPV -> DVR
```
Following the previous rename patches, it should be the case that there
are no instances of any of these strings that are meant to refer to the
general case of DbgRecords, or anything other than the DPValue class.
The idea behind this patch is therefore that pure string substitution is
correct in all cases as long as these assumptions hold.
2024-03-19 20:07:07 +00:00
|
|
|
DbgVariableRecord *DVR =
|
|
|
|
DbgVariableRecord::createDVRDeclare(Storage, VarInfo, Expr, DL);
|
2025-02-13 10:46:42 +00:00
|
|
|
insertDbgVariableRecord(DVR, InsertPt);
|
[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)
This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which reflects
the updated terminology for the "final" implementation of the RemoveDI
feature. This is a pure string substitution + clang-format patch. The
only manual component of this patch was determining where to perform
these string substitutions: `DPValue` and `DPV` are almost exclusively
used for DbgRecords, *except* for:
- llvm/lib/target, where 'DP' is used to mean double-precision, and so
appears as part of .td files and in variable names. NB: There is a
single existing use of `DPValue` here that refers to debug info, which
I've manually updated.
- llvm/tools/gold, where 'LDPV' is used as a prefix for symbol
visibility enums.
Outside of these places, I've applied several basic string
substitutions, with the intent that they only affect DbgRecord-related
identifiers; I've checked them as I went through to verify this, with
reasonable confidence that there are no unintended changes that slipped
through the cracks. The substitutions applied are all case-sensitive,
and are applied in the order shown:
```
DPValue -> DbgVariableRecord
DPVal -> DbgVarRec
DPV -> DVR
```
Following the previous rename patches, it should be the case that there
are no instances of any of these strings that are meant to refer to the
general case of DbgRecords, or anything other than the DPValue class.
The idea behind this patch is therefore that pure string substitution is
correct in all cases as long as these assumptions hold.
2024-03-19 20:07:07 +00:00
|
|
|
return DVR;
|
2024-03-12 10:25:58 +00:00
|
|
|
}
|
|
|
|
|
2010-12-07 23:25:47 +00:00
|
|
|
if (!DeclareFn)
|
2017-09-21 19:52:03 +00:00
|
|
|
DeclareFn = getDeclareIntrin(M);
|
2010-12-07 23:25:47 +00:00
|
|
|
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-09 18:38:53 +00:00
|
|
|
trackIfUnresolved(VarInfo);
|
|
|
|
trackIfUnresolved(Expr);
|
|
|
|
Value *Args[] = {getDbgIntrinsicValueImpl(VMContext, Storage),
|
|
|
|
MetadataAsValue::get(VMContext, VarInfo),
|
|
|
|
MetadataAsValue::get(VMContext, Expr)};
|
2010-12-07 23:25:47 +00:00
|
|
|
|
2020-02-16 17:46:26 +01:00
|
|
|
IRBuilder<> B(DL->getContext());
|
2025-02-13 10:46:42 +00:00
|
|
|
initIRBuilder(B, DL, InsertPt);
|
2017-10-03 20:36:40 +00:00
|
|
|
return B.CreateCall(DeclareFn, Args);
|
2010-12-07 23:25:47 +00:00
|
|
|
}
|
|
|
|
|
[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)
This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which reflects
the updated terminology for the "final" implementation of the RemoveDI
feature. This is a pure string substitution + clang-format patch. The
only manual component of this patch was determining where to perform
these string substitutions: `DPValue` and `DPV` are almost exclusively
used for DbgRecords, *except* for:
- llvm/lib/target, where 'DP' is used to mean double-precision, and so
appears as part of .td files and in variable names. NB: There is a
single existing use of `DPValue` here that refers to debug info, which
I've manually updated.
- llvm/tools/gold, where 'LDPV' is used as a prefix for symbol
visibility enums.
Outside of these places, I've applied several basic string
substitutions, with the intent that they only affect DbgRecord-related
identifiers; I've checked them as I went through to verify this, with
reasonable confidence that there are no unintended changes that slipped
through the cracks. The substitutions applied are all case-sensitive,
and are applied in the order shown:
```
DPValue -> DbgVariableRecord
DPVal -> DbgVarRec
DPV -> DVR
```
Following the previous rename patches, it should be the case that there
are no instances of any of these strings that are meant to refer to the
general case of DbgRecords, or anything other than the DPValue class.
The idea behind this patch is therefore that pure string substitution is
correct in all cases as long as these assumptions hold.
2024-03-19 20:07:07 +00:00
|
|
|
void DIBuilder::insertDbgVariableRecord(DbgVariableRecord *DVR,
|
2025-02-13 10:46:42 +00:00
|
|
|
InsertPosition InsertPt) {
|
|
|
|
assert(InsertPt.isValid());
|
[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)
This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which reflects
the updated terminology for the "final" implementation of the RemoveDI
feature. This is a pure string substitution + clang-format patch. The
only manual component of this patch was determining where to perform
these string substitutions: `DPValue` and `DPV` are almost exclusively
used for DbgRecords, *except* for:
- llvm/lib/target, where 'DP' is used to mean double-precision, and so
appears as part of .td files and in variable names. NB: There is a
single existing use of `DPValue` here that refers to debug info, which
I've manually updated.
- llvm/tools/gold, where 'LDPV' is used as a prefix for symbol
visibility enums.
Outside of these places, I've applied several basic string
substitutions, with the intent that they only affect DbgRecord-related
identifiers; I've checked them as I went through to verify this, with
reasonable confidence that there are no unintended changes that slipped
through the cracks. The substitutions applied are all case-sensitive,
and are applied in the order shown:
```
DPValue -> DbgVariableRecord
DPVal -> DbgVarRec
DPV -> DVR
```
Following the previous rename patches, it should be the case that there
are no instances of any of these strings that are meant to refer to the
general case of DbgRecords, or anything other than the DPValue class.
The idea behind this patch is therefore that pure string substitution is
correct in all cases as long as these assumptions hold.
2024-03-19 20:07:07 +00:00
|
|
|
trackIfUnresolved(DVR->getVariable());
|
|
|
|
trackIfUnresolved(DVR->getExpression());
|
|
|
|
if (DVR->isDbgAssign())
|
|
|
|
trackIfUnresolved(DVR->getAddressExpression());
|
2024-03-12 10:25:58 +00:00
|
|
|
|
2025-02-13 10:46:42 +00:00
|
|
|
auto *BB = InsertPt.getBasicBlock();
|
|
|
|
BB->insertDbgRecordBefore(DVR, InsertPt);
|
2024-03-12 10:25:58 +00:00
|
|
|
}
|
|
|
|
|
2022-01-16 12:44:52 -08:00
|
|
|
Instruction *DIBuilder::insertDbgIntrinsic(llvm::Function *IntrinsicFn,
|
|
|
|
Value *V, DILocalVariable *VarInfo,
|
|
|
|
DIExpression *Expr,
|
|
|
|
const DILocation *DL,
|
2025-02-13 10:46:42 +00:00
|
|
|
InsertPosition InsertPt) {
|
2022-01-16 12:44:52 -08:00
|
|
|
assert(IntrinsicFn && "must pass a non-null intrinsic function");
|
|
|
|
assert(V && "must pass a value to a dbg intrinsic");
|
|
|
|
assert(VarInfo &&
|
|
|
|
"empty or invalid DILocalVariable* passed to debug intrinsic");
|
2015-04-15 21:18:07 +00:00
|
|
|
assert(DL && "Expected debug loc");
|
|
|
|
assert(DL->getScope()->getSubprogram() ==
|
|
|
|
VarInfo->getScope()->getSubprogram() &&
|
|
|
|
"Expected matching subprograms");
|
2010-12-07 23:25:47 +00:00
|
|
|
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-09 18:38:53 +00:00
|
|
|
trackIfUnresolved(VarInfo);
|
|
|
|
trackIfUnresolved(Expr);
|
|
|
|
Value *Args[] = {getDbgIntrinsicValueImpl(VMContext, V),
|
|
|
|
MetadataAsValue::get(VMContext, VarInfo),
|
|
|
|
MetadataAsValue::get(VMContext, Expr)};
|
2015-04-15 21:18:07 +00:00
|
|
|
|
2020-02-16 17:46:26 +01:00
|
|
|
IRBuilder<> B(DL->getContext());
|
2025-02-13 10:46:42 +00:00
|
|
|
initIRBuilder(B, DL, InsertPt);
|
2022-01-16 12:44:52 -08:00
|
|
|
return B.CreateCall(IntrinsicFn, Args);
|
2010-12-07 23:25:47 +00:00
|
|
|
}
|
2014-12-18 00:46:16 +00:00
|
|
|
|
2024-03-12 10:25:58 +00:00
|
|
|
DbgInstPtr DIBuilder::insertLabel(DILabel *LabelInfo, const DILocation *DL,
|
2025-02-13 10:46:42 +00:00
|
|
|
InsertPosition InsertPt) {
|
[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.
In order to set breakpoints on labels and list source code around
labels, we need collect debug information for labels, i.e., label
name, the function label belong, line number in the file, and the
address label located. In order to keep these information in LLVM
IR and to allow backend to generate debug information correctly.
We create a new kind of metadata for labels, DILabel. The format
of DILabel is
!DILabel(scope: !1, name: "foo", file: !2, line: 3)
We hope to keep debug information as much as possible even the
code is optimized. So, we create a new kind of intrinsic for label
metadata to avoid the metadata is eliminated with basic block.
The intrinsic will keep existing if we keep it from optimized out.
The format of the intrinsic is
llvm.dbg.label(metadata !1)
It has only one argument, that is the DILabel metadata. The
intrinsic will follow the label immediately. Backend could get the
label metadata through the intrinsic's parameter.
We also create DIBuilder API for labels to be used by Frontend.
Frontend could use createLabel() to allocate DILabel objects, and use
insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.
Differential Revision: https://reviews.llvm.org/D45024
Patch by Hsiangkai Wang.
llvm-svn: 331841
2018-05-09 02:40:45 +00:00
|
|
|
assert(LabelInfo && "empty or invalid DILabel* passed to dbg.label");
|
|
|
|
assert(DL && "Expected debug loc");
|
|
|
|
assert(DL->getScope()->getSubprogram() ==
|
|
|
|
LabelInfo->getScope()->getSubprogram() &&
|
|
|
|
"Expected matching subprograms");
|
2024-03-12 10:25:58 +00:00
|
|
|
|
|
|
|
trackIfUnresolved(LabelInfo);
|
|
|
|
if (M.IsNewDbgInfoFormat) {
|
2024-03-20 13:11:28 +00:00
|
|
|
DbgLabelRecord *DLR = new DbgLabelRecord(LabelInfo, DL);
|
2025-02-13 10:46:42 +00:00
|
|
|
if (InsertPt.isValid()) {
|
|
|
|
auto *BB = InsertPt.getBasicBlock();
|
|
|
|
BB->insertDbgRecordBefore(DLR, InsertPt);
|
|
|
|
}
|
2024-03-20 13:11:28 +00:00
|
|
|
return DLR;
|
2024-03-12 10:25:58 +00:00
|
|
|
}
|
|
|
|
|
[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.
In order to set breakpoints on labels and list source code around
labels, we need collect debug information for labels, i.e., label
name, the function label belong, line number in the file, and the
address label located. In order to keep these information in LLVM
IR and to allow backend to generate debug information correctly.
We create a new kind of metadata for labels, DILabel. The format
of DILabel is
!DILabel(scope: !1, name: "foo", file: !2, line: 3)
We hope to keep debug information as much as possible even the
code is optimized. So, we create a new kind of intrinsic for label
metadata to avoid the metadata is eliminated with basic block.
The intrinsic will keep existing if we keep it from optimized out.
The format of the intrinsic is
llvm.dbg.label(metadata !1)
It has only one argument, that is the DILabel metadata. The
intrinsic will follow the label immediately. Backend could get the
label metadata through the intrinsic's parameter.
We also create DIBuilder API for labels to be used by Frontend.
Frontend could use createLabel() to allocate DILabel objects, and use
insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.
Differential Revision: https://reviews.llvm.org/D45024
Patch by Hsiangkai Wang.
llvm-svn: 331841
2018-05-09 02:40:45 +00:00
|
|
|
if (!LabelFn)
|
2024-10-11 05:26:03 -07:00
|
|
|
LabelFn = Intrinsic::getOrInsertDeclaration(&M, Intrinsic::dbg_label);
|
[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.
In order to set breakpoints on labels and list source code around
labels, we need collect debug information for labels, i.e., label
name, the function label belong, line number in the file, and the
address label located. In order to keep these information in LLVM
IR and to allow backend to generate debug information correctly.
We create a new kind of metadata for labels, DILabel. The format
of DILabel is
!DILabel(scope: !1, name: "foo", file: !2, line: 3)
We hope to keep debug information as much as possible even the
code is optimized. So, we create a new kind of intrinsic for label
metadata to avoid the metadata is eliminated with basic block.
The intrinsic will keep existing if we keep it from optimized out.
The format of the intrinsic is
llvm.dbg.label(metadata !1)
It has only one argument, that is the DILabel metadata. The
intrinsic will follow the label immediately. Backend could get the
label metadata through the intrinsic's parameter.
We also create DIBuilder API for labels to be used by Frontend.
Frontend could use createLabel() to allocate DILabel objects, and use
insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.
Differential Revision: https://reviews.llvm.org/D45024
Patch by Hsiangkai Wang.
llvm-svn: 331841
2018-05-09 02:40:45 +00:00
|
|
|
|
|
|
|
Value *Args[] = {MetadataAsValue::get(VMContext, LabelInfo)};
|
|
|
|
|
2020-02-16 17:46:26 +01:00
|
|
|
IRBuilder<> B(DL->getContext());
|
2025-02-13 10:46:42 +00:00
|
|
|
initIRBuilder(B, DL, InsertPt);
|
[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.
In order to set breakpoints on labels and list source code around
labels, we need collect debug information for labels, i.e., label
name, the function label belong, line number in the file, and the
address label located. In order to keep these information in LLVM
IR and to allow backend to generate debug information correctly.
We create a new kind of metadata for labels, DILabel. The format
of DILabel is
!DILabel(scope: !1, name: "foo", file: !2, line: 3)
We hope to keep debug information as much as possible even the
code is optimized. So, we create a new kind of intrinsic for label
metadata to avoid the metadata is eliminated with basic block.
The intrinsic will keep existing if we keep it from optimized out.
The format of the intrinsic is
llvm.dbg.label(metadata !1)
It has only one argument, that is the DILabel metadata. The
intrinsic will follow the label immediately. Backend could get the
label metadata through the intrinsic's parameter.
We also create DIBuilder API for labels to be used by Frontend.
Frontend could use createLabel() to allocate DILabel objects, and use
insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.
Differential Revision: https://reviews.llvm.org/D45024
Patch by Hsiangkai Wang.
llvm-svn: 331841
2018-05-09 02:40:45 +00:00
|
|
|
return B.CreateCall(LabelFn, Args);
|
|
|
|
}
|
|
|
|
|
2021-11-11 13:39:50 -08:00
|
|
|
void DIBuilder::replaceVTableHolder(DICompositeType *&T, DIType *VTableHolder) {
|
2015-04-07 04:12:02 +00:00
|
|
|
{
|
2015-04-29 16:38:44 +00:00
|
|
|
TypedTrackingMDRef<DICompositeType> N(T);
|
2016-04-23 21:08:00 +00:00
|
|
|
N->replaceVTableHolder(VTableHolder);
|
2015-04-07 04:12:02 +00:00
|
|
|
T = N.get();
|
|
|
|
}
|
2014-12-18 00:46:16 +00:00
|
|
|
|
|
|
|
// If this didn't create a self-reference, just return.
|
|
|
|
if (T != VTableHolder)
|
|
|
|
return;
|
|
|
|
|
2015-02-11 17:45:10 +00:00
|
|
|
// Look for unresolved operands. T will drop RAUW support, orphaning any
|
|
|
|
// cycles underneath it.
|
|
|
|
if (T->isResolved())
|
|
|
|
for (const MDOperand &O : T->operands())
|
|
|
|
if (auto *N = dyn_cast_or_null<MDNode>(O))
|
|
|
|
trackIfUnresolved(N);
|
2014-12-18 00:46:16 +00:00
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
void DIBuilder::replaceArrays(DICompositeType *&T, DINodeArray Elements,
|
|
|
|
DINodeArray TParams) {
|
2015-04-07 04:12:02 +00:00
|
|
|
{
|
2015-04-29 16:38:44 +00:00
|
|
|
TypedTrackingMDRef<DICompositeType> N(T);
|
2015-04-07 04:12:02 +00:00
|
|
|
if (Elements)
|
2015-04-07 04:14:33 +00:00
|
|
|
N->replaceElements(Elements);
|
2015-04-07 04:12:02 +00:00
|
|
|
if (TParams)
|
2015-04-29 16:38:44 +00:00
|
|
|
N->replaceTemplateParams(DITemplateParameterArray(TParams));
|
2015-04-07 04:12:02 +00:00
|
|
|
T = N.get();
|
|
|
|
}
|
2014-12-18 00:46:16 +00:00
|
|
|
|
|
|
|
// If T isn't resolved, there's no problem.
|
|
|
|
if (!T->isResolved())
|
|
|
|
return;
|
|
|
|
|
2015-07-10 23:26:02 +00:00
|
|
|
// If T is resolved, it may be due to a self-reference cycle. Track the
|
2014-12-18 00:46:16 +00:00
|
|
|
// arrays explicitly if they're unresolved, or else the cycles will be
|
|
|
|
// orphaned.
|
|
|
|
if (Elements)
|
2015-04-07 16:50:39 +00:00
|
|
|
trackIfUnresolved(Elements.get());
|
2014-12-18 00:46:16 +00:00
|
|
|
if (TParams)
|
2015-04-07 16:50:39 +00:00
|
|
|
trackIfUnresolved(TParams.get());
|
2014-12-18 00:46:16 +00:00
|
|
|
}
|