[DebugInfo][RemoveDIs] Find types hidden in DbgRecords (#106547)

When serialising to textual IR, there can be constant Values referred to
by DbgRecords that don't appear anywhere else, and have typ

[DebugInfo][RemoveDIs] Find types hidden in DbgRecords (#106547)

When serialising to textual IR, there can be constant Values referred to
by DbgRecords that don't appear anywhere else, and have types hidden
even deeper in side them. Enumerate these when enumerating all types.

Test by Mikael Holmén.

show more ...

Reapply "[DebugInfo] Make DIArgList inherit from Metadata and always unique"

This reverts commit 0fd5dc94380d5fe666dc6c603b4bb782cef743e7.

The original commit removed DIArgLists from being in an MD

Reapply "[DebugInfo] Make DIArgList inherit from Metadata and always unique"

This reverts commit 0fd5dc94380d5fe666dc6c603b4bb782cef743e7.

The original commit removed DIArgLists from being in an MDNode map, but did
not insert a new `delete` in the LLVMContextImpl destructor. This
reapply adds that call to delete, preventing a memory leak.

show more ...

Revert "[DebugInfo] Make DIArgList inherit from Metadata and always unique" (#72682)

Reverts llvm/llvm-project#72147

Reverted due to buildbot failure:
https://lab.llvm.org/buildbot/#/builders/5/

Revert "[DebugInfo] Make DIArgList inherit from Metadata and always unique" (#72682)

Reverts llvm/llvm-project#72147

Reverted due to buildbot failure:
https://lab.llvm.org/buildbot/#/builders/5/builds/38410

show more ...

[DebugInfo] Make DIArgList inherit from Metadata and always unique (#72147)

This patch changes the `DIArgList` class's inheritance from `MDNode` to
`Metadata, ReplaceableMetadataImpl`, and ensures

[DebugInfo] Make DIArgList inherit from Metadata and always unique (#72147)

This patch changes the `DIArgList` class's inheritance from `MDNode` to
`Metadata, ReplaceableMetadataImpl`, and ensures that it is always
unique, i.e. a distinct DIArgList should never be produced.

This should not result in any changes to IR or bitcode parsing and
printing, as the format for DIArgList is unchanged, and the order in which it
appears should also be identical. As a minor note, this patch also fixes
a gap in the verifier, where the ValueAsMetadata operands to a DIArgList
would not be visited.

show more ...

[IR] Support ifuncs in opaque pointer mode

Relax the type assertion for opaque pointers, and enumerate the
value type in TypeFinder and ValueEnumerator.

[TypeFinder] Support opaque pointers

We need to explicitly visit a number of types, as these are no
longer reachable through the pointer type if opaque pointers are
enabled. This is similar to Value

[TypeFinder] Support opaque pointers

We need to explicitly visit a number of types, as these are no
longer reachable through the pointer type if opaque pointers are
enabled. This is similar to ValueEnumerator changes that have
been done previously.

show more ...

[llvm] Use range-based for loops (NFC)

[IR] Make TypeFinder aware of DIArgList values

TypeFinder did not find types under DIArgList. This resulted in a case
of invalid IR after GlobalOpt removed a global that was the only
non-DIArgList u

[IR] Make TypeFinder aware of DIArgList values

TypeFinder did not find types under DIArgList. This resulted in a case
of invalid IR after GlobalOpt removed a global that was the only
non-DIArgList use of a struct type.

error: use of undefined type named 'struct.S'
call void @llvm.dbg.value(
metadata !DIArgList([1 x %struct.S]* undef, i64 %idxprom),
metadata !24, metadata !DIExpression([...]))

Reviewed By: jmorse

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

show more ...

[NFC] Fixes -Wrange-loop-analysis warnings

This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall.

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

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Use ranged for loops in TypeFinder.cpp, NFC

llvm-svn: 324628

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

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

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

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

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

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

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

llvm-svn: 304787

show more ...

[IR] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 295383

Apply clang-tidy's modernize-loop-convert to most of lib/IR.

Only minor manual fixes. No functionality change intended.

llvm-svn: 273813

Re-reapply "[IR] Move optional data in llvm::Function into a hungoff uselist"

Make personality functions, prefix data, and prologue data hungoff
operands of Function.

This is based on the email thr

Re-reapply "[IR] Move optional data in llvm::Function into a hungoff uselist"

Make personality functions, prefix data, and prologue data hungoff
operands of Function.

This is based on the email thread "[RFC] Clean up the way we store
optional Function data" on llvm-dev.

Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback!

Includes a fix to scrub value subclass data in dropAllReferences. Does not
use binary literals.

Differential Revision: http://reviews.llvm.org/D13829

llvm-svn: 256095

show more ...

Revert "Reapply "[IR] Move optional data in llvm::Function into a hungoff uselist""

This reverts commit r256093.

This broke lld-x86_64-win7 because of -Werror,-Wc++1y-extensions.

llvm-svn: 256094

Reapply "[IR] Move optional data in llvm::Function into a hungoff uselist"

Make personality functions, prefix data, and prologue data hungoff
operands of Function.

This is based on the email thread

Reapply "[IR] Move optional data in llvm::Function into a hungoff uselist"

Make personality functions, prefix data, and prologue data hungoff
operands of Function.

This is based on the email thread "[RFC] Clean up the way we store
optional Function data" on llvm-dev.

Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback!

Includes a fix to scrub value subclass data in dropAllReferences.

Differential Revision: http://reviews.llvm.org/D13829

llvm-svn: 256093

show more ...

Revert "[IR] Move optional data in llvm::Function into a hungoff uselist"

This reverts commit r256090.

This broke llvm-clang-lld-x86_64-debian-fast.

llvm-svn: 256091

[IR] Move optional data in llvm::Function into a hungoff uselist

Make personality functions, prefix data, and prologue data hungoff
operands of Function.

This is based on the email thread "[RFC] Cl

[IR] Move optional data in llvm::Function into a hungoff uselist

Make personality functions, prefix data, and prologue data hungoff
operands of Function.

This is based on the email thread "[RFC] Clean up the way we store
optional Function data" on llvm-dev.

Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback!

Differential Revision: http://reviews.llvm.org/D13829

llvm-svn: 256090

show more ...

IR: Remove implicit iterator conversions from lib/IR, NFC

Stop converting implicitly between iterators and pointers/references in
lib/IR. For convenience, I've added a `getIterator()` accessor to
`

IR: Remove implicit iterator conversions from lib/IR, NFC

Stop converting implicitly between iterators and pointers/references in
lib/IR. For convenience, I've added a `getIterator()` accessor to
`ilist_node` so that callers don't need to know how to spell the
iterator class (i.e., they can use `X.getIterator()` instead of
`Function::iterator(X)`).

I'll eventually disallow these implicit conversions entirely, but
there's a lot of code, so it doesn't make sense to do it all in one
patch. One library or so at a time.

Why? To root out cases of `getNextNode()` and `getPrevNode()` being
used in iterator logic. The design of `ilist` makes that invalid when
the current node could be at the back of the list, but it happens to
"work" right now because of a bug where those functions never return
`nullptr` if you're using a half-node sentinel. Before I can fix the
function, I have to remove uses of it that rely on it misbehaving.
(Maybe the function should just be deleted anyway? But I don't want
deleting it -- potentially a huge project -- to block fixing
ilist/iplist.)

llvm-svn: 249782

show more ...

Move the personality function from LandingPadInst to Function

The personality routine currently lives in the LandingPadInst.

This isn't desirable because:
- All LandingPadInsts in the same function

Move the personality function from LandingPadInst to Function

The personality routine currently lives in the LandingPadInst.

This isn't desirable because:
- All LandingPadInsts in the same function must have the same
personality routine. This means that each LandingPadInst beyond the
first has an operand which produces no additional information.

- There is ongoing work to introduce EH IR constructs other than
LandingPadInst. Moving the personality routine off of any one
particular Instruction and onto the parent function seems a lot better
than have N different places a personality function can sneak onto an
exceptional function.

Differential Revision: http://reviews.llvm.org/D10429

llvm-svn: 239940

show more ...

Fix Value dangling reference debug output

llvm-svn: 231889

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 I

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

show more ...

Prologue support

Patch by Ben Gamari!

This redefines the `prefix` attribute introduced previously and
introduces a `prologue` attribute. There are a two primary usecases
that these attributes aim

Prologue support

Patch by Ben Gamari!

This redefines the `prefix` attribute introduced previously and
introduces a `prologue` attribute. There are a two primary usecases
that these attributes aim to serve,

1. Function prologue sigils

2. Function hot-patching: Enable the user to insert `nop` operations
at the beginning of the function which can later be safely replaced
with a call to some instrumentation facility

3. Runtime metadata: Allow a compiler to insert data for use by the
runtime during execution. GHC is one example of a compiler that
needs this functionality for its tables-next-to-code functionality.

Previously `prefix` served cases (1) and (2) quite well by allowing the user
to introduce arbitrary data at the entrypoint but before the function
body. Case (3), however, was poorly handled by this approach as it
required that prefix data was valid executable code.

Here we redefine the notion of prefix data to instead be data which
occurs immediately before the function entrypoint (i.e. the symbol
address). Since prefix data now occurs before the function entrypoint,
there is no need for the data to be valid code.

The previous notion of prefix data now goes under the name "prologue
data" to emphasize its duality with the function epilogue.

The intention here is to handle cases (1) and (2) with prologue data and
case (3) with prefix data.

References
----------

This idea arose out of discussions[1] with Reid Kleckner in response to a
proposal to introduce the notion of symbol offsets to enable handling of
case (3).

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073235.html

Test Plan: testsuite

Differential Revision: http://reviews.llvm.org/D6454

llvm-svn: 223189

show more ...

Revert "IR: MDNode => Value"

Instead, we're going to separate metadata from the Value hierarchy. See
PR21532.

This reverts commit r221375.
This reverts commit r221373.
This reverts commit r221359.

Revert "IR: MDNode => Value"

Instead, we're going to separate metadata from the Value hierarchy. See
PR21532.

This reverts commit r221375.
This reverts commit r221373.
This reverts commit r221359.
This reverts commit r221167.
This reverts commit r221027.
This reverts commit r221024.
This reverts commit r221023.
This reverts commit r220995.
This reverts commit r220994.

llvm-svn: 221711

show more ...