Commit Graph

14 Commits

Author SHA1 Message Date
Alexey Samsonov
f79e2d40b2 Fix UBSan error reports in ValueMapCallbackVH and AssertingVH<T> empty/tombstone keys generation.
Summary:
One more attempt to fix UBSan reports: make sure DenseMapInfo::getEmptyKey()
and DenseMapInfo::getTombstoneKey() doesn't do any upcasts/downcasts to/from Value*.

Test Plan: check-llvm test suite with/without UBSan bootstrap

Reviewers: chandlerc, dexonsmith

Subscribers: llvm-commits, majnemer

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225558 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-09 23:17:25 +00:00
Duncan P. N. Exon Smith
f700a24774 Fix another GCC build failure from r223802
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:59:09 +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
Dylan Noblesmith
389f13012f Support: add llvm::unique_lock
Based on the STL class of the same name, it guards a mutex
while also allowing it to be unlocked conditionally before
destruction.

This eliminates the last naked usages of mutexes in LLVM and
clang.

It also uncovered and fixed a bug in callExternalFunction()
when compiled without USE_LIBFFI, where the mutex would never
be unlocked if the end of the function was reached.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216338 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-23 23:07:14 +00:00
Dylan Noblesmith
d930a30833 Support: make LLVM Mutexes STL-compatible
Use lock/unlock() convention instead of acquire/release().

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216336 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-23 22:49:22 +00:00
Zachary Turner
91e18f7639 Revert "Replace Execution Engine's mutex with std::recursive_mutex."
This reverts commit 1f502bd9d7, due to
GCC / MinGW's lack of support for C++11 threading.

It's possible this will go back in after we come up with a
reasonable solution.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211401 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-20 21:07:14 +00:00
Yaron Keren
212e2b9c8d Reverting size_type for the containers from size_type to unsigned.
Various places in LLVM assume that container size and count are unsigned
and do not use the container size_type. Therefore they break compilation
(or possibly executation) for LP64 systems where size_t is 64 bit while
unsigned is still 32 bit.

If we'll ever that many items in the container size_type could be made
size_t for a specific containers after reviweing its other uses.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211353 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-20 12:20:56 +00:00
Yaron Keren
ed4e8a839f The count() function for STL datatypes returns unsigned, even where it's
only 1/0 result like std::set. Some of the LLVM ADT already return unsigned
count(), while others still return bool count().

In continuation to r197879, this patch modifies DenseMap, DenseSet, 
ScopedHashTable, ValueMap:: count() to return size_type instead of bool,
1 instead of true and 0 instead of false.

size_type is typedef-ed locally within each class to size_t.

http://reviews.llvm.org/D4018

Reviewed by dblaikie.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211350 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-20 10:26:56 +00:00
Zachary Turner
1f502bd9d7 Replace Execution Engine's mutex with std::recursive_mutex.
This change has a bit of a trickle down effect due to the fact that
there are a number of derived implementations of ExecutionEngine,
and that the mutex is not tightly encapsulated so is used by other
classes directly.

Reviewed by: rnk

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211214 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-18 20:17:35 +00:00
Zachary Turner
84fea7720c Expose ValueMap's mutex type as a typedef instead of a sys::Mutex.
This enables static polymorphism of the mutex type, which is
necessary in order to replace the standard mutex implementation
with a different type.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211080 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-17 00:17:38 +00:00
Craig Topper
4ba844388c [C++11] More 'nullptr' conversion. In some cases just using a boolean check instead of comparing to nullptr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206142 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-14 00:51:57 +00:00
Benjamin Kramer
c1dafe8dc3 [C++11] Replace LLVM-style type traits with C++11 standard ones.
No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203242 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-07 14:42:25 +00:00
Craig Topper
01394fb9e4 [C++11] Add 'override' keyword to virtual methods that override their base class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202946 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-05 07:52:44 +00:00
Chandler Carruth
7225e27b4c [Modules] Move ValueMap to the IR library. While this class does not
directly care about the Value class (it is templated so that the key can
be any arbitrary Value subclass), it is in fact concretely tied to the
Value class through the ValueHandle's CallbackVH interface which relies
on the key type being some Value subclass to establish the value handle
chain.

Ironically, the unittest is already in the right library.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202824 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-04 11:26:31 +00:00