Commit Graph

833 Commits

Author SHA1 Message Date
Yaron Keren
80237c1148 Fix Visual C++ error "'llvm::make_unique' : ambiguous call to overloaded function".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224506 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-18 10:03:35 +00:00
Rafael Espindola
d15bca6859 Modernize the getStreamedBitcodeModule interface a bit. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224499 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-18 05:08:43 +00:00
Nick Lewycky
9451a382ed Make ValueEnumerator::print use OS for metadata too. Noticed by inspection.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224404 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-17 01:52:08 +00:00
Duncan P. N. Exon Smith
b0d1b981e8 Bitcode: Add missing "Remove in 4.0" comments
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224090 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-12 02:11:31 +00:00
Duncan P. N. Exon Smith
4bedb48751 Bitcode: Use unsigned char to record MDStrings
`MDString`s can have arbitrary characters in them.  Prevent an assertion
that fired in `BitcodeWriter` because of sign extension by copying the
characters into the record as `unsigned char`s.

Based on a patch by Keno Fischer; fixes PR21882.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224077 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-11 23:34:30 +00:00
Duncan P. N. Exon Smith
e39dba9f07 Bitcode: Add METADATA_NODE and METADATA_VALUE
This reflects the typelessness of `Metadata` in the bitcode format,
removing types from all metadata operands.

`METADATA_VALUE` represents a `ValueAsMetadata`, and always has two
fields: the type and the value.

`METADATA_NODE` represents an `MDNode`, and unlike `METADATA_OLD_NODE`,
doesn't store types.  It stores operands at their ID+1 so that `0` can
reference `nullptr` operands.

Part of PR21532.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224073 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-11 23:02:24 +00:00
Duncan P. N. Exon Smith
934da0fc3f Bitcode: Add OLD_ prefix to metadata node records
I'm about to change these, so move the old ones out of the way.

Part of PR21532.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224070 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-11 22:30:48 +00:00
Duncan P. N. Exon Smith
dad20b2ae2 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.)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:38:53 +00:00
Duncan P. N. Exon Smith
09ba28c27c IR: Disallow function-local metadata attachments
Metadata attachments to instructions cannot be function-local.

This is part of PR21532.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223574 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-06 02:29:44 +00:00
Duncan P. N. Exon Smith
30596886ed IR: Disallow complicated function-local metadata
Disallow complex types of function-local metadata.  The only valid
function-local metadata is an `MDNode` whose sole argument is a
non-metadata function-local value.

Part of PR21532.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223564 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-06 01:26:49 +00:00
Rafael Espindola
eee41dbb65 Ask the module for its the identified types.
When lazy reading a module, the types used in a function will not be visible to
a TypeFinder until the body is read.

This patch fixes that by asking the module for its identified struct types.
If a materializer is present, the module asks it. If not, it uses a TypeFinder.

This fixes pr21374.

I will be the first to say that this is ugly, but it was the best I could find.

Some of the options I looked at:

* Asking the LLVMContext. This could be made to work for gold, but not currently
  for ld64. ld64 will load multiple modules into a single context before merging
  them. This causes us to see types from future merges. Unfortunately,
  MappedTypes is not just a cache when it comes to opaque types. Once the
  mapping has been made, we have to remember it for as long as the key may
  be used. This would mean moving MappedTypes to the Linker class and having
  to drop the Linker::LinkModules static methods, which are visible from C.

* Adding an option to ignore function bodies in the TypeFinder. This would
  fix the PR by picking the worst result. It would work, but unfortunately
  we are currently quite dependent on the upfront type merging. I will
  try to reduce our dependency, but it is not clear that we will be able
  to get rid of it for now.

The only clean solution I could think of is making the Module own the types.
This would have other advantages, but it is a much bigger change. I will
propose it, but it is nice to have this fixed while that is discussed.

With the gold plugin, this patch takes the number of types in the LTO clang
binary from 52817 to 49669.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223215 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-03 07:18:23 +00:00
Peter Collingbourne
bb660fc192 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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223189 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-03 02:08:38 +00:00
Rafael Espindola
468d2fc5ca Add and use Type::subtypes. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222682 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-24 20:44:36 +00:00
Richard Trieu
c670d3bfc3 Add accessor marcos to ConstantPlaceHolder, similar to those in the base class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222502 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-21 02:42:08 +00:00
Rafael Espindola
dfeee31cac Pass a reference to ValueEnumerator.
NFC. This will just make it easier to use std::unique_ptr in a caller.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222170 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-17 20:06:27 +00:00
Reid Kleckner
b036e71e41 Silence MSVC warning on missing return after fully covered switch
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221943 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-13 23:07:22 +00:00
Rafael Espindola
83e56d6b47 Move calls to push_back out of readAbbreviated(Literal|Field).
These functions always return a single value and not all callers want to
push them into a SmallVector.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221934 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-13 22:29:02 +00:00
Rafael Espindola
b92db75a03 Make a few helper functions static. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221930 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-13 21:54:59 +00:00
Rafael Espindola
d0ab58245f Return the number of read bytes in MemoryObject::readBytes.
Returning more information will allow BitstreamReader to be simplified a bit
and changed to read 64 bits at a time.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-12 17:11:16 +00:00
Rafael Espindola
8c2a55264a Reduce code duplication a bit. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221785 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-12 14:48:38 +00:00
Duncan P. N. Exon Smith
5bf8ade9d0 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221711 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-11 21:30:22 +00:00
Rafael Espindola
8e617cceb1 Factor out call to push_back. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221490 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-06 22:39:16 +00:00
Duncan P. N. Exon Smith
5e84760dde IR: MDNode => Value: Instruction::getAllMetadataOtherThanDebugLoc()
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
2014-11-03 18:13:57 +00:00
Rafael Espindola
5793838fc8 Remove redundant calls to isMaterializable.
This removes calls to isMaterializable in the following cases:

* It was redundant with a call to isDeclaration now that isDeclaration returns
  the correct answer for materializable functions.
* It was followed by a call to Materialize. Just call Materialize and check EC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221050 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-01 16:46:18 +00:00
NAKAMURA Takumi
0d36b9d692 Untabify.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220884 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-29 23:44:35 +00:00
Rafael Espindola
c498284e46 Modernize the error handling of the Materialize function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220600 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-24 22:50:48 +00:00
Rafael Espindola
68b02dcd54 Don't ever call materializeAllPermanently during LTO.
To do this, change the representation of lazy loaded functions.

The previous representation cannot differentiate between a function whose body
has been removed and one whose body hasn't been read from the .bc file. That
means that in order to drop a function, the entire body had to be read.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220580 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-24 18:13:04 +00:00
Rafael Espindola
8b8e2b2f81 clang-format two code snippets to make the next patch easy to read.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220484 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-23 15:20:05 +00:00
Duncan P. N. Exon Smith
cb3866e72e IR: Reorder metadata bitcode serialization, NFC
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
2014-10-21 22:27:47 +00:00
Duncan P. N. Exon Smith
9fa8641288 IR: Remove dead code in metadata bitcode writing, NFC
No one cares how many uses each metadata value has, so don't bother
counting.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220337 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-21 22:13:34 +00:00
Sanjay Patel
ddcfe81459 correct const-ness with auto and dyn_cast
1. Use const with autos.
2. Don't bother with explicit const in cast ops because they do it automagically.

Thanks, David B. / Aaron B. / Reid K.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219817 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-15 17:45:13 +00:00
Sanjay Patel
5af49c83c3 Use 'auto' for easier reading; no functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219804 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-15 16:21:37 +00:00
Peter Collingbourne
75202eb0c6 Introduce LLVMWriteBitcodeToMemoryBuffer C API function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219643 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-14 00:30:59 +00:00
Petar Jovanovic
fd42335e83 Do not destroy external linkage when deleting function body
The function deleteBody() converts the linkage to external and thus destroys
original linkage type value. Lack of correct linkage type causes wrong
relocations to be emitted later.
Calling dropAllReferences() instead of deleteBody() will fix the issue.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218302 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-23 12:54:19 +00:00
Chris Bieneman
4ea1a1185a Eliminating static destructor for the BitCodeErrorCategory by converting to a ManagedStatic.
Summary: This is part of the overall goal of removing static initializers from LLVM.

Reviewers: chandlerc

Reviewed By: chandlerc

Subscribers: chandlerc, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218149 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 20:29:02 +00:00
Benjamin Kramer
57a73c27b1 Use IntrusiveRefCntPtr to manage the lifetime of BitCodeAbbrevs.
This doesn't change the interface or gives additional safety but removes
a ton of retain/release boilerplate.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217778 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-15 15:44:14 +00:00
Rafael Espindola
6d66a1cd2f Pass a && to getLazyBitcodeModule.
This forces callers to use std::move when calling it. It is somewhat odd to have
code with std::move that doesn't always move, but it is also odd to have code
without std::move that sometimes moves.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217049 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-03 17:31:46 +00:00
Rafael Espindola
aa9db69bb5 Fix a double free in llvm::getBitcodeTargetTriple.
Unfortunately this is only used by ld64, so no testcase, but should fix the darwin LTO bootstrap.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216618 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-27 21:11:13 +00:00
Rafael Espindola
fb1af0a48a Pass a std::unique_ptr<MemoryBuffer>& to getLazyBitcodeModule.
By taking a reference we can do the ownership transfer in one place instead of
expecting every caller to do it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216492 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-26 22:00:09 +00:00
Rafael Espindola
2292996e1a Pass a MemoryBufferRef when we can avoid taking ownership.
The attached patch simplifies a few interfaces that don't need to take
ownership of a buffer.

For example, both parseAssembly and parseBitcodeFile will parse the
entire buffer before returning. There is no need to take ownership.

Using a MemoryBufferRef makes it obvious in the type signature that
there is no ownership transfer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216488 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-26 21:49:01 +00:00
Rafael Espindola
8c96862847 Modernize raw_fd_ostream's constructor a bit.
Take a StringRef instead of a "const char *".
Take a "std::error_code &" instead of a "std::string &" for error.

A create static method would be even better, but this patch is already a bit too
big.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216393 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-25 18:16:47 +00:00
Duncan P. N. Exon Smith
1d8c9d95bf BitcodeReader: Only create one basic block for each blockaddress
Block address forward-references are implemented by creating a
`BasicBlock` ahead of time that gets inserted in the `Function` when
it's eventually encountered.

However, if the same blockaddress was used in two separate functions
that were parsed *before* the referenced function (and the blockaddress
was never used at global scope), two separate basic blocks would get
created, one of which would be forgotten creating invalid IR.

This commit changes the forward-reference logic to create only one basic
block (and always return the same blockaddress).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215805 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-16 01:54:37 +00:00
Duncan P. N. Exon Smith
1e97329f27 UseListOrder: Correctly count the number of uses
This is an off-by-one bug I found by inspection, which would only
trigger if the bitcode writer sees more uses of a `Value` than the
reader.  Since this is only relevant when an instruction gets upgraded
somehow, there unfortunately isn't a reasonable way to add test
coverage.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215804 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-16 01:54:34 +00:00
Benjamin Kramer
00e08fcaa0 Canonicalize header guards into a common format.
Add header guards to files that were missing guards. Remove #endif comments
as they don't seem common in LLVM (we can easily add them back if we decide
they're useful)

Changes made by clang-tidy with minor tweaks.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215558 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-13 16:26:38 +00:00
Duncan P. N. Exon Smith
7f2cd21ddd BitcodeReader: Fix non-determinism in use-list order
`BasicBlockFwdRefs` (and `BlockAddrFwdRefs` before it) was being emptied
in a non-deterministic order.  When predicting use-list order I've
worked around this another way, but even when parsing lazily (and we
can't recreate use-list order) use-lists should be deterministic.

Make them so by using a side-queue of functions with forward-referenced
blocks that gets visited in order.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214899 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-05 17:49:48 +00:00
Duncan P. N. Exon Smith
1526278443 UseListOrder: Fix blockaddress use-list order
`parseBitcodeFile()` uses the generic `getLazyBitcodeFile()` function as
a helper.  Since `parseBitcodeFile()` isn't actually lazy -- it calls
`MaterializeAllPermanently()` -- bypass the unnecessary call to
`materializeForwardReferencedFunctions()` by extracting out a common
helper function.  This removes the last of the use-list churn caused by
blockaddresses.

This highlights that we can't reproduce use-list order of globals and
constants when parsing lazily -- but that's necessarily out of scope.
When we're parsing lazily, we never have all the functions in memory, so
the use-lists of globals (and constants that reference globals) are
always incomplete.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214581 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-01 22:27:19 +00:00
Duncan P. N. Exon Smith
147851ef9d BitcodeReader: Change mechanics of BlockAddress forward references, NFC
Now that we can reliably handle forward references to `BlockAddress`
(r214563), change the mechanics to simplify predicting use-list order.

Previously, we created dummy `GlobalVariable`s to represent block
addresses.  After every function was materialized, we'd go through any
forward references to its blocks and RAUW them with a proper
`BlockAddress` constant.  This causes some (potentially a lot of)
unnecessary use-list churn, since any constant expression that it's a
part of will need to be rematerialized as well.

Instead, pre-construct a `BasicBlock` immediately -- without attaching
it to its (empty) `Function` -- and use that to construct a
`BlockAddress`.  This constant will not have to be regenerated.  When
the function body is parsed, hook this pre-constructed basic block up
in the right place using `BasicBlock::insertInto()`.

Both before and after this change, the IR is temporarily in an invalid
state that gets resolved when `materializeForwardReferencedFunctions()`
gets called.

This is a prep commit that's part of PR5680, but the only functionality
change is the reduction of churn in the constant pool.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214570 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-01 21:51:52 +00:00
Duncan P. N. Exon Smith
cf8b959e8d BitcodeReader: Fix some BlockAddress forward reference corner cases
`BlockAddress`es are interesting in that they can reference basic blocks
from *outside* the block's function.  Since basic blocks are not global
values, this presents particular challenges for lazy parsing.

One corner case was found in PR11677 and fixed in r147425.  In that
case, a global variable references a block address.  It's necessary to
load the relevant function to resolve the forward reference before doing
anything with the module.

By inspection, I found (and have fixed here) two other cases:

  - An instruction from one function references a block address from
    another function, and only the first function is lazily loaded.

    I fixed this the same way as PR11677: by eagerly loading the
    referenced function.

  - A function whose block address is taken is dematerialized, leaving
    invalid references to it.

    I fixed this by refusing to dematerialize functions whose block
    addresses are taken (if you have to load it, you can't unload it).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214559 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-01 21:11:34 +00:00
Duncan P. N. Exon Smith
9d65d3717c UseListOrder: Handle self-users
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
2014-07-31 18:33:12 +00:00
Duncan P. N. Exon Smith
e5ae09b08f UseListOrder: Don't give constant IDs to GlobalValues
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
2014-07-31 00:13:28 +00:00