Change `Instruction::getAllMetadataOtherThanDebugLoc()` from a vector of
`MDNode` to one of `Value`. Part of PR21433.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221167 91177308-0d34-0410-b5e6-96231b3b80d8
Enumerate `MDNode`'s operands *before* the node itself, so that the
reader requires less RAUW. Although this will cause different code
paths to be hit in the reader, this should effectively be no
functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220340 91177308-0d34-0410-b5e6-96231b3b80d8
Correctly sort self-users (such as PHI nodes). I added a targeted test
in `test/Bitcode/use-list-order.ll` and the final missing RUN line to
tests in `test/Assembly`.
This is part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214417 91177308-0d34-0410-b5e6-96231b3b80d8
Since initializers of GlobalValues are being assigned IDs before
GlobalValues themselves, explicitly exclude GlobalValues from the
constant pool. Added targeted test in `test/Bitcode/use-list-order.ll`
and added two more RUN lines in `test/Assembly`.
This is part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214368 91177308-0d34-0410-b5e6-96231b3b80d8
When predicting use-list order, we visit functions in reverse order
followed by `GlobalValue`s and write out use-lists at the first
opportunity. In the reader, this will translate to *after* the last use
has been added.
For this to work, we actually need to descend into `GlobalValue`s.
Added a targeted test in `use-list-order.ll` and `RUN` lines to the
newly passing tests in `test/Bitcode`.
There are two remaining failures in `test/Bitcode`:
- blockaddress.ll: I haven't thought through how to model the way
block addresses change the order of use-lists (or how to work around
it).
- metadata-2.ll: There's an old-style `@llvm.used` global array here
that I suspect the .ll parser isn't upgrading properly. When it
round-trips through bitcode, the .bc reader *does* upgrade it, so
the extra variable (`i8* null`) has an extra use, and the shuffle
vector doesn't match.
I think the fix is to upgrade old-style global arrays (or reject
them?) in the .ll parser.
This is part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214321 91177308-0d34-0410-b5e6-96231b3b80d8
This commit fixes undefined behaviour that caused the revert in r214249.
The problem was two unsequenced operations on a `DenseMap<>`, giving
different behaviour in GCC and Clang. This:
DenseMap<T*, unsigned> DM;
for (auto &X : ...)
DM[&X] = DM.size() + 1;
should have been:
DenseMap<T*, unsigned> DM;
for (auto &X : ...) {
unsigned Size = DM.size();
DM[&X] = Size + 1;
}
Until r214242, this difference between compilers didn't matter. In
r214242, `OrderMap::LastGlobalValueID` was introduced and compared
against IDs, which in GCC were off-by-one my expectations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214270 91177308-0d34-0410-b5e6-96231b3b80d8
To avoid unnecessary forward references, the reader doesn't process
initializers of `GlobalValue`s until after the constant pool has been
processed, and then in reverse order. Model this when predicting
use-list order. This gets two more Bitcode tests passing with
`llvm-uselistorder`.
Part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214242 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the sort of expected order in the reader to correctly return `false`
when comparing a `Use` against itself.
This was caught by test/Bitcode/binaryIntInstructions.3.2.ll, so I'm
adding a `RUN` line using `llvm-uselistorder` for every test in
`test/Bitcode` that passes.
A few tests still fail, so I'll investigate those next.
This is part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214157 91177308-0d34-0410-b5e6-96231b3b80d8
Since we're storing lots of these, save two-pointers per vector with a
custom type rather than using the relatively heavy `SmallVector`.
Part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214135 91177308-0d34-0410-b5e6-96231b3b80d8
Predict and serialize use-list order in bitcode. This makes the option
`-preserve-bc-use-list-order` work *most* of the time, but this is still
experimental.
- Builds a full value-table up front in the writer, sets up a list of
use-list orders to write out, and discards the table. This is a
simpler first step than determining the order from the various
overlapping IDs of values on-the-fly.
- The shuffles stored in the use-list order list have an unnecessarily
large memory footprint.
- `blockaddress` expressions cause functions to be materialized
out-of-order. For now I've ignored this problem, so use-list orders
will be wrong for constants used by functions that have block
addresses taken. There are a couple of ways to fix this, but I
don't have a concrete plan yet.
- When materializing functions lazily, the use-lists for constants
will not be correct. This use case is out of scope: what should the
use-list order be, if it's incomplete?
This is part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214125 91177308-0d34-0410-b5e6-96231b3b80d8
`ValueEnumerator::OptimizeConstants()` creates forward references within
the constant pools, which makes predicting constants' use-list order
difficult. For now, just disable the optimization.
This can be re-enabled in the future in one of two ways:
- Enable a limited version of this optimization that doesn't create
forward references. One idea is to categorize constants by their
"height" and make that the top-level sort.
- Enable it entirely. This requires predicting how may times each
constant will be recreated as its operands' and operands' operands'
(etc.) forward references get resolved.
This is part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213953 91177308-0d34-0410-b5e6-96231b3b80d8
This new IR facility allows us to represent the object-file semantic of
a COMDAT group.
COMDATs allow us to tie together sections and make the inclusion of one
dependent on another. This is required to implement features like MS
ABI VFTables and optimizing away certain kinds of initialization in C++.
This functionality is only representable in COFF and ELF, Mach-O has no
similar mechanism.
Differential Revision: http://reviews.llvm.org/D4178
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211920 91177308-0d34-0410-b5e6-96231b3b80d8
This requires a number of steps.
1) Move value_use_iterator into the Value class as an implementation
detail
2) Change it to actually be a *Use* iterator rather than a *User*
iterator.
3) Add an adaptor which is a User iterator that always looks through the
Use to the User.
4) Wrap these in Value::use_iterator and Value::user_iterator typedefs.
5) Add the range adaptors as Value::uses() and Value::users().
6) Update *all* of the callers to correctly distinguish between whether
they wanted a use_iterator (and to explicitly dig out the User when
needed), or a user_iterator which makes the Use itself totally
opaque.
Because #6 requires churning essentially everything that walked the
Use-Def chains, I went ahead and added all of the range adaptors and
switched them to range-based loops where appropriate. Also because the
renaming requires at least churning every line of code, it didn't make
any sense to split these up into multiple commits -- all of which would
touch all of the same lies of code.
The result is still not quite optimal. The Value::use_iterator is a nice
regular iterator, but Value::user_iterator is an iterator over User*s
rather than over the User objects themselves. As a consequence, it fits
a bit awkwardly into the range-based world and it has the weird
extra-dereferencing 'operator->' that so many of our iterators have.
I think this could be fixed by providing something which transforms
a range of T&s into a range of T*s, but that *can* be separated into
another patch, and it isn't yet 100% clear whether this is the right
move.
However, this change gets us most of the benefit and cleans up
a substantial amount of code around Use and User. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203364 91177308-0d34-0410-b5e6-96231b3b80d8
Duncan P. N. Exon Smith
David Majnemer
Rafael Espindola
Chandler Carruth
Benjamin Kramer
Peter Collingbourne
Joe Abbey
Bill Wendling