Commit Graph

38 Commits

Author SHA1 Message Date
Manman Ren
0d12d4ebc6 [llvm link] Destroy ConstantArrays in LLVMContext if they are not used.
ConstantArrays constructed during linking can cause quadratic memory
explosion. An example is the ConstantArrays constructed when linking in
GlobalVariables with appending linkage.

Releasing all unused constants can cause a 20% LTO compile-time
slowdown for a large application. So this commit releases unused ConstantArrays
only.

rdar://19040716. It reduces memory footprint from 20+G to 6+G.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226592 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-20 19:24:59 +00:00
Duncan P. N. Exon Smith
47ddb76984 IR: Delete GenericDwarfNode during teardown
Fix a leak in `LLVMContextImpl` teardown that the leak sanitizer tracked
down [1].  I've just switched to automatic dispatch here (since I'll
inevitably forget again with the next class).

[1]: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/811/steps/check-llvm%20asan/logs/stdio

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226536 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-20 01:18:32 +00:00
Duncan P. N. Exon Smith
0a9f921686 IR: Introduce GenericDwarfNode
As part of PR22235, introduce `DwarfNode` and `GenericDwarfNode`.  The
former is a metadata node with a DWARF tag.  The latter matches our
current (generic) schema of a header with string (and stringified
integer) data and an arbitrary number of operands.

This doesn't move it into place yet; that change will require a large
number of testcase updates.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226529 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-20 00:01:43 +00:00
Duncan P. N. Exon Smith
b0617860b5 IR: Merge UniquableMDNode back into MDNode, NFC
As pointed out in r226501, the distinction between `MDNode` and
`UniquableMDNode` is confusing.  When we need subclasses of `MDNode`
that don't use all its functionality it might make sense to break it
apart again, but until then this makes the code clearer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226520 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-19 23:13:14 +00:00
Duncan P. N. Exon Smith
fce53dd939 IR: Extract MDNodeOpsKey, NFC
Make the MDTuple operand hashing logic reusable.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226519 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-19 22:53:18 +00:00
Philip Reames
07fbc5c1c6 Move ownership of GCStrategy objects to LLVMContext
Note: This change ended up being slightly more controversial than expected.  Chandler has tentatively okayed this for the moment, but I may be revisiting this in the near future after we settle some high level questions.

Rather than have the GCStrategy object owned by the GCModuleInfo - which is an immutable analysis pass used mainly by gc.root - have it be owned by the LLVMContext. This simplifies the ownership logic (i.e. can you have two instances of the same strategy at once?), but more importantly, allows us to access the GCStrategy in the middle end optimizer. To this end, I add an accessor through Function which becomes the canonical way to get at a GCStrategy instance.

In the near future, this will allows me to move some of the checks from http://reviews.llvm.org/D6808 into the Verifier itself, and to introduce optimization legality predicates for some of the recent additions to InstCombine. (These will follow as separate changes.)

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226311 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-16 20:07:33 +00:00
Duncan P. N. Exon Smith
0294f639d2 IR: Drop metadata references more aggressively during teardown
Sometimes teardown happens before the debug info graph is complete
(e.g., when clang throws an error).  In that case, `MDNode`s will still
have RAUW, so deleting constants that the `MDNode`s point at will be
relatively expensive -- it'll cause re-uniquing all up the chain (what
I've been referring to as "teardown madness").

So, drop references *before* deleting constants.  We need to drop a few
more references now: the metadata side of the metadata/value bridges
needs to be dropped off the cliff along with the rest of it (previously,
the bridges were cleaned before we did anything with the `MDNode`s).

There's no real functionality change here -- state before and after
`LLVMContextImpl::~LLVMContextImpl()` is unchanged -- so no testcase.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226044 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-14 21:58:17 +00:00
Duncan P. N. Exon Smith
d640962656 IR: Add MDLocation class
Add a new subclass of `UniquableMDNode`, `MDLocation`.  This will be the
IR version of `DebugLoc` and `DILocation`.  The goal is to rename this
to `DILocation` once the IR classes supersede the `DI`-prefixed
wrappers.

This isn't used anywhere yet.  Part of PR21433.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225824 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-13 20:44:56 +00:00
Duncan P. N. Exon Smith
343bb3e252 IR: Prepare for a new UniquableMDNode subclass, NFC
Add generic dispatch for the parts of `UniquableMDNode` that cast to
`MDTuple`.  This makes adding other subclasses (like PR21433's
`MDLocation`) easier.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225697 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-12 20:56:33 +00:00
Duncan P. N. Exon Smith
d1ec4f037d IR: Stop erasing MDNodes from uniquing sets during teardown
Stop erasing `MDNode`s from the uniquing sets in `LLVMContextImpl`
during teardown (in particular, during
`UniquableMDNode::~UniquableMDNode()`).  Although it's currently
feasible, there isn't any clear benefit and it may not be feasible for
other subclasses (which don't explicitly store the lookup hash).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225696 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-12 20:50:25 +00:00
Duncan P. N. Exon Smith
ae9e15f914 IR: Split GenericMDNode into MDTuple and UniquableMDNode
Split `GenericMDNode` into two classes (with more descriptive names).

  - `UniquableMDNode` will be a common subclass for `MDNode`s that are
    sometimes uniqued like constants, and sometimes 'distinct'.

    This class gets the (short-lived) RAUW support and related API.

  - `MDTuple` is the basic tuple that has always been returned by
    `MDNode::get()`.  This is as opposed to more specific nodes to be
    added soon, which have additional fields, custom assembly syntax,
    and extra semantics.

    This class gets the hash-related logic, since other sublcasses of
    `UniquableMDNode` may need to hash based on other fields.

To keep this diff from getting too big, I've added casts to `MDTuple`
that won't really scale as new subclasses of `UniquableMDNode` are
added, but I'll clean those up incrementally.

(No functionality change intended.)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225682 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-12 20:09:34 +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
David Blaikie
25efc8dbce Revert "unique_ptrify LLVMContextImpl::CAZConstants"
Missed the complexities of how these elements are destroyed.

This reverts commit r222714.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222715 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-25 02:26:22 +00:00
David Blaikie
bf3afab75a unique_ptrify LLVMContextImpl::CAZConstants
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222714 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-25 02:13:54 +00:00
Duncan P. N. Exon Smith
023c72e64a IR: Move MDNode operands from the back to the front
Having the operands at the back prevents subclasses from safely adding
fields.  Move them to the front.

Instead of replicating the custom `malloc()`, `free()` and `DestroyFlag`
logic that was there before, overload `new` and `delete`.

I added calls to a new `GenericMDNode::dropAllReferences()` in
`LLVMContextImpl::~LLVMContextImpl()`.  There's a maze of callbacks
happening during teardown, and this resolves them before we enter
the destructors.

Part of PR21532.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222211 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-18 01:56:14 +00:00
Duncan P. N. Exon Smith
2c38b004d9 IR: Split MDNode into GenericMDNode and MDNodeFwdDecl
Split `MDNode` into two classes:

  - `GenericMDNode`, which is uniquable (and for now, always starts
    uniqued).  Once `Metadata` is split from the `Value` hierarchy, this
    class will lose the ability to RAUW itself.

  - `MDNodeFwdDecl`, which is used for the "temporary" interface, is
    never uniqued, and isn't managed by `LLVMContext` at all.

I've left most of the guts in `MDNode` for now, but I'll incrementally
move things to the right places (or delete the functionality, as
appropriate).

Part of PR21532.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222205 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-18 00:37:17 +00:00
Duncan P. N. Exon Smith
66a2b0564e IR: Simplify uniquing for MDNode
Change uniquing from a `FoldingSet` to a `DenseSet` with custom
`DenseMapInfo`.  Unfortunately, this doesn't save any memory, since
`DenseSet<T>` is a simple wrapper for `DenseMap<T, char>`, but I'll come
back to fix that later.

I used the name `GenericDenseMapInfo` to the custom `DenseMapInfo` since
I'll be splitting `MDNode` into two classes soon: `MDNodeFwdDecl` for
temporaries, and `GenericMDNode` for everything else.

I also added a non-debug-info reduced version of a type-uniquing test
that started failing on an earlier draft of this patch.

Part of PR21532.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222191 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-17 23:28:21 +00:00
Duncan P. N. Exon Smith
ed7bdcaf03 IR: Rewrite uniquing and creation of MDString
Stop using `Value::getName()` to get the string behind an `MDString`.
Switch to `StringMapEntry<MDString>` so that we can find the string by
its coallocation.

This is part of PR21532.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221960 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-14 01:17:09 +00:00
Duncan P. N. Exon Smith
04d2186546 LTO: Ignore disabled diagnostic remarks
r206400 and r209442 added remarks that are disabled by default.
However, if a diagnostic handler is registered, the remarks are sent
unfiltered to the handler.  This is the right behaviour for clang, since
it has its own filters.

However, the diagnostic handler exposed in the LTO API receives only the
severity and message.  It doesn't have the information to filter by pass
name.  For LTO, disabled remarks should be filtered by the producer.

I've changed `LLVMContext::setDiagnosticHandler()` to take a `bool`
argument indicating whether to respect the built-in filters.  This
defaults to `false`, so other consumers don't have a behaviour change,
but `LTOCodeGenerator::setDiagnosticHandler()` sets it to `true`.

To make this behaviour testable, I added a `-use-diagnostic-handler`
command-line option to `llvm-lto`.

This fixes PR21108.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218784 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 18:36:03 +00:00
Duncan P. N. Exon Smith
7116af637c Reapply r215966, r215965, r215964, r215963, r215960, r215959, r215958, and r215957
This reverts commit r215981, which reverted the above commits because
MSVC std::equal asserts on nullptr iterators, and thes commits
introduced an `ArrayRef::equals()` on empty ArrayRefs.

ArrayRef was changed not to use std::equal in r215986.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215987 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 16:39:58 +00:00
Aaron Ballman
93710f07f0 Reverting r215966, r215965, r215964, r215963, r215960, r215959, r215958, and r215957 (these commits all rely on previous commits) due to build breakage. These commits cause failed assertions when testing Clang using MSVC 2013. The asserts are triggered from the std::equal call within ArrayRef::equals due to being passed invalid input (ArrayRef.begin() is returning a nullptr which is problematic).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215981 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 14:59:02 +00:00
Duncan P. N. Exon Smith
78c0b35bf7 IR: Rewrite ConstantUniqueMap
Rewrite `ConstantUniqueMap` to be more similar to
`ConstantAggrUniqueMap`.

  - Use a `DenseMap` with custom MapInfo instead of a `std::map` with
    linear lookups and deletion.
  - Don't waste memory explicitly storing (heavyweight) keys.

Only `ConstantExpr` and `InlineAsm` actually use this data structure, so
I also updated them to use it.

This code cleanup is a precursor to reducing RAUW traffic on
`ConstantExpr` -- I felt badly adding a new (linear) call to
`ConstantUniqueMap::FindExistingKey`, so this designs away the concern.

A follow-up commit will transition the users of `ConstantAggrUniqueMap`
over.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215957 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 00:42:32 +00:00
Diego Novillo
c64771062b Remove LLVMContextImpl::optimizationRemarkEnabledFor.
Summary:
This patch moves the handling of -pass-remarks* over to
lib/DiagnosticInfo.cpp. This allows the removal of the
optimizationRemarkEnabledFor functions from LLVMContextImpl, as they're
not needed anymore.

Reviewers: qcolombet

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209453 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-22 17:19:01 +00:00
Diego Novillo
d16404a0e7 Add support for missed and analysis optimization remarks.
Summary:
This adds two new diagnostics: -pass-remarks-missed and
-pass-remarks-analysis. They take the same values as -pass-remarks but
are intended to be triggered in different contexts.

-pass-remarks-missed is used by LLVMContext::emitOptimizationRemarkMissed,
which passes call when they tried to apply a transformation but
couldn't.

-pass-remarks-analysis is used by LLVMContext::emitOptimizationRemarkAnalysis,
which passes call when they want to inform the user about analysis
results.

The patch also:

1- Adds support in the inliner for the two new remarks and a
   test case.

2- Moves emitOptimizationRemark* functions to the llvm namespace.

3- Adds an LLVMContext argument instead of making them member functions
   of LLVMContext.

Reviewers: qcolombet

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209442 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-22 14:19:46 +00:00
Juergen Ributzka
9bc1b73c9e Add C API for thread yielding callback.
Sometimes a LLVM compilation may take more time then a client would like to
wait for. The problem is that it is not possible to safely suspend the LLVM
thread from the outside. When the timing is bad it might be possible that the
LLVM thread holds a global mutex and this would block any progress in any other
thread.

This commit adds a new yield callback function that can be registered with a
context. LLVM will try to yield by calling this callback function, but there is
no guaranteed frequency. LLVM will only do so if it can guarantee that
suspending the thread won't block any forward progress in other LLVM contexts
in the same process.

Once the client receives the call back it can suspend the thread safely and
resume it at another time.

Related to <rdar://problem/16728690>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208945 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-16 02:33:15 +00:00
Juergen Ributzka
218bad2bc5 Revert "[PM] Add pass run listeners to the pass manager."
Revert the current implementation and C API. New implementation and C APIs are
in the works.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208904 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-15 17:49:20 +00:00
Diego Novillo
e3e870face Do not make -pass-remarks additive.
Summary:
When I initially introduced -pass-remarks, I thought it would be a
neat idea to make it additive. So, if one used it as:

$ llc -pass-remarks=inliner --pass-remarks=loop.*

the compiler would build the regular expression '(inliner)|(loop.*)'.

The more I think about it, the more I regret it. This is not how
other flags work. The standard semantics are right-to-left overrides.

This is how clang interprets -Rpass. And I think the two should be
compatible in this respect.

Reviewers: qcolombet

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208122 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-06 19:14:00 +00:00
Juergen Ributzka
4e0cc51d79 [PM] Add pass run listeners to the pass manager.
This commit provides the necessary C/C++ APIs and infastructure to enable fine-
grain progress report and safe suspension points after each pass in the pass
manager.

Clients can provide a callback function to the pass manager to call after each
pass. This can be used in a variety of ways (progress report, dumping of IR
between passes, safe suspension of threads, etc).

The run listener list is maintained in the LLVMContext, which allows a multi-
threaded client to be only informed for it's own thread. This of course assumes
that the client created a LLVMContext for each thread.

This fixes <rdar://problem/16728690>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207430 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-28 18:19:25 +00:00
David Blaikie
b86fbcb08c Simplify destruction of Modules in LLVContextImpl.
This avoids copying the container by simply deleting until empty.

While I'd rather move to a stricter ownership semantic (unique_ptr),
SmallPtrSet can't cope with unique_ptr and the ownership semantics here
are a bit incestuous (Module sort of owns itself, but sort of doesn't
(if the LLVMContext is destroyed before the Module, then it deregisters
itself from the context... )).

Ideally Modules would be given to the context, or possibly an
emplace-like function to construct them there. Modules then shouldn't be
destroyed by LLVM API clients, but by interacting with the owner
(LLVMContext) directly (but even then, passing a Module* to LLVMContext
doesn't provide an easy way to destroy the Module, since the set would
be over unique_ptrs and you'd need a heterogenous lookup function which
SmallPtrSet doesn't have either).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-21 21:27:19 +00:00
Craig Topper
ec0f0bc6af [C++11] More 'nullptr' conversion or in some cases just using a boolean check instead of comparing to nullptr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205831 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-09 06:08:46 +00:00
Diego Novillo
35d647b6f3 Add -pass-remarks flag to 'opt'.
Summary:
This adds support in 'opt' to filter pass remarks emitted by
optimization passes. A new flag -pass-remarks specifies which
passes should emit a diagnostic when LLVMContext::emitOptimizationRemark
is invoked.

This will allow the front end to simply pass along the regular
expression from its own -Rpass flag when launching the backend.

Depends on D3227.

Reviewers: qcolombet

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D3291

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205775 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-08 16:42:38 +00:00
Quentin Colombet
de262fecd2 Add warning capabilities in LLVM.
This reapplies r197438 and fixes the link-time circular dependency between
IR and Support. The fix consists in moving the diagnostic support into IR.

The patch adds a new LLVMContext::diagnose that can be used to communicate to
the front-end, if any, that something of interest happened.
The diagnostics are supported by a new abstraction, the DiagnosticInfo class.
The base class contains the following information:
- The kind of the report: What this is about.
- The severity of the report: How bad this is.

This patch also adds 2 classes:
- DiagnosticInfoInlineAsm: For inline asm reporting. Basically, this diagnostic
will be used to switch to the new diagnostic API for LLVMContext::emitError.
- DiagnosticStackSize: For stack size reporting. Comes as a replacement of the
hard coded warning in PEI.

This patch also features dynamic diagnostic identifiers. In other words plugins
can use this infrastructure for their own diagnostics (for more details, see
getNextAvailablePluginDiagnosticKind).

This patch introduces a new DiagnosticHandlerTy and a new DiagnosticContext in
the LLVMContext that should be set by the front-end to be able to map these
diagnostics in its own system.

http://llvm-reviews.chandlerc.com/D2376
<rdar://problem/15515174>


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197508 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-17 17:47:22 +00:00
Quentin Colombet
e0c25bd05d Revert r197438 and r197447 until we figure out how to avoid circular dependency at link time
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197451 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-17 01:19:59 +00:00
Quentin Colombet
b6c4a84592 Add warning capabilities in LLVM.
The patch adds a new LLVMContext::diagnose that can be used to communicate to
the front-end, if any, that something of interest happened.
The diagnostics are supported by a new abstraction, the DiagnosticInfo class.
The base class contains the following information:
- The kind of the report: What this is about.
- The severity of the report: How bad this is.

This patch also adds 2 classes:
- DiagnosticInfoInlineAsm: For inline asm reporting. Basically, this diagnostic
will be used to switch to the new diagnostic API for LLVMContext::emitError.
- DiagnosticStackSize: For stack size reporting. Comes as a replacement of the
hard coded warning in PEI.

This patch also features dynamic diagnostic identifiers. In other words plugins
can use this infrastructure for their own diagnostics (for more details, see
getNextAvailablePluginDiagnosticKind).

This patch introduces a new DiagnosticHandlerTy and a new DiagnosticContext in
the LLVMContext that should be set by the front-end to be able to map these
diagnostics in its own system.

http://llvm-reviews.chandlerc.com/D2376
<rdar://problem/15515174>


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197438 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-16 23:22:51 +00:00
Bob Wilson
f64c889cc9 Revert "Rename LLVMContext diagnostic handler types and functions."
This reverts my commit 171047. Now that I've removed my misguided attempt to
support backend warnings, these diagnostics are only about inline assembly.
It would take quite a bit more work to generalize them properly, so I'm
just reverting this.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174860 91177308-0d34-0410-b5e6-96231b3b80d8
2013-02-11 05:37:07 +00:00
Bill Wendling
8b1f2f3b70 Cleanup the AttributeSetNodes that we create.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173311 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-24 00:14:46 +00:00
Chandler Carruth
0b8c9a80f2 Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-02 11:36:10 +00:00
Chandler Carruth
c2c50cdcdc Rename VMCore directory to IR.
Aside from moving the actual files, this patch only updates the build
system and the source file comments under lib/... that are relevant.

I'll be updating other docs and other files in smaller subsequnet
commits.

While I've tried to test this, but it is entirely possible that there
will still be some build system fallout.

Also, note that I've not changed the library name itself: libLLVMCore.a
is still the library name. I'd be interested in others' opinions about
whether we should rename this as well (I think we should, just not sure
what it might break)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171359 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-02 09:10:48 +00:00