summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/LLVMContextImpl.h
Commit message (Collapse)AuthorAgeFilesLines
...
* [llvm link] Destroy ConstantArrays in LLVMContext if they are not used.Manman Ren2015-01-201-0/+3
| | | | | | | | | | | | | | 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. llvm-svn: 226592
* IR: Introduce GenericDwarfNodeDuncan P. N. Exon Smith2015-01-201-8/+53
| | | | | | | | | | | | 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. llvm-svn: 226529
* IR: Merge UniquableMDNode back into MDNode, NFCDuncan P. N. Exon Smith2015-01-191-1/+1
| | | | | | | | | 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. llvm-svn: 226520
* IR: Extract MDNodeOpsKey, NFCDuncan P. N. Exon Smith2015-01-191-23/+48
| | | | | | Make the MDTuple operand hashing logic reusable. llvm-svn: 226519
* Move ownership of GCStrategy objects to LLVMContextPhilip Reames2015-01-161-0/+12
| | | | | | | | | | | | 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 llvm-svn: 226311
* IR: Add MDLocation classDuncan P. N. Exon Smith2015-01-131-0/+43
| | | | | | | | | | | 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. llvm-svn: 225824
* IR: Split GenericMDNode into MDTuple and UniquableMDNodeDuncan P. N. Exon Smith2015-01-121-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | 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.) llvm-svn: 225682
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-091-59/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Turn some DenseMaps that are only used for set operations into DenseSets.Benjamin Kramer2014-12-061-5/+5
| | | | | | DenseSet has better memory efficiency now. llvm-svn: 223589
* Reapply "LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP ↵Benjamin Kramer2014-12-061-39/+22
| | | | | | | | DenseMaps." This reapplies r223478 with a fix for 32 bit targets. llvm-svn: 223586
* Reformat.NAKAMURA Takumi2014-12-061-26/+18
| | | | llvm-svn: 223580
* Revert "LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP ↵Benjamin Kramer2014-12-061-15/+46
| | | | | | | | | DenseMaps." Somehow made DenseMap probe on forever on 32 bit machines. This reverts commit r223478. llvm-svn: 223546
* LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP DenseMaps.Benjamin Kramer2014-12-051-46/+15
| | | | | | | | Required some APInt massaging to get proper empty/tombstone values. Apart from making the code a bit simpler this also reduces the bucket size of the ConstantInt map from 32 to 24 bytes. llvm-svn: 223478
* Prologue supportPeter Collingbourne2014-12-031-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "unique_ptrify LLVMContextImpl::CAZConstants"David Blaikie2014-11-251-4/+1
| | | | | | | | Missed the complexities of how these elements are destroyed. This reverts commit r222714. llvm-svn: 222715
* unique_ptrify LLVMContextImpl::CAZConstantsDavid Blaikie2014-11-251-1/+4
| | | | llvm-svn: 222714
* Add params() to FunctionType. NFC.Rafael Espindola2014-11-211-4/+3
| | | | | | While at it, also use makeArrayRef in elements(). llvm-svn: 222556
* Add and use a helper elements() to StructType. NFC.Rafael Espindola2014-11-211-3/+2
| | | | llvm-svn: 222553
* IR: Split MDNode into GenericMDNode and MDNodeFwdDeclDuncan P. N. Exon Smith2014-11-181-13/+13
| | | | | | | | | | | | | | | | | | | 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. llvm-svn: 222205
* IR: Simplify uniquing for MDNodeDuncan P. N. Exon Smith2014-11-171-16/+46
| | | | | | | | | | | | | | | | | | 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. llvm-svn: 222191
* IR: Rewrite uniquing and creation of MDStringDuncan P. N. Exon Smith2014-11-141-1/+1
| | | | | | | | | | 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. llvm-svn: 221960
* LTO: Ignore disabled diagnostic remarksDuncan P. N. Exon Smith2014-10-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 218784
* Simplify creation of a bunch of ArrayRefs by using None, makeArrayRef or ↵Craig Topper2014-08-271-1/+1
| | | | | | just letting them be implicitly created. llvm-svn: 216525
* Reapply r215966, r215965, r215964, r215963, r215960, r215959, r215958, and ↵Duncan P. N. Exon Smith2014-08-191-8/+6
| | | | | | | | | | | | 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. llvm-svn: 215987
* Reverting r215966, r215965, r215964, r215963, r215960, r215959, r215958, and ↵Aaron Ballman2014-08-191-6/+8
| | | | | | 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). llvm-svn: 215981
* IR: Replace uses of ConstantAggrUniqueMap with ConstantUniqueMapDuncan P. N. Exon Smith2014-08-191-4/+4
| | | | | | | Now that `ConstantAggrUniqueMap` and `ConstantUniqueMap` work the same way, change the aggregates to use the new one. llvm-svn: 215959
* IR: Rewrite ConstantUniqueMapDuncan P. N. Exon Smith2014-08-191-4/+2
| | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 215957
* Canonicalize header guards into a common format.Benjamin Kramer2014-08-131-2/+2
| | | | | | | | | | 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. llvm-svn: 215558
* Remove LLVMContextImpl::optimizationRemarkEnabledFor.Diego Novillo2014-05-221-9/+0
| | | | | | | | | | | | | | | | 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 llvm-svn: 209453
* Add support for missed and analysis optimization remarks.Diego Novillo2014-05-221-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 209442
* Add C API for thread yielding callback.Juergen Ributzka2014-05-161-0/+3
| | | | | | | | | | | | | | | | | | | | | 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> llvm-svn: 208945
* Revert "[PM] Add pass run listeners to the pass manager."Juergen Ributzka2014-05-151-15/+1
| | | | | | | Revert the current implementation and C API. New implementation and C APIs are in the works. llvm-svn: 208904
* [PM] Add pass run listeners to the pass manager.Juergen Ributzka2014-04-281-1/+15
| | | | | | | | | | | | | | | | | | 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> llvm-svn: 207430
* [C++] Use 'nullptr'.Craig Topper2014-04-281-2/+2
| | | | llvm-svn: 207394
* Add -pass-remarks flag to 'opt'.Diego Novillo2014-04-081-0/+4
| | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 205775
* [C++11] Add 'override' keyword to IR library.Craig Topper2014-03-051-3/+3
| | | | llvm-svn: 202939
* [Modules] Move ValueHandle into the IR library where Value itself lives.Chandler Carruth2014-03-041-1/+1
| | | | | | | | | | | Move the test for this class into the IR unittests as well. This uncovers that ValueMap too is in the IR library. Ironically, the unittest for ValueMap is useless in the Support library (honestly, so was the ValueHandle test) and so it already lives in the IR unittests. Mmmm, tasty layering. llvm-svn: 202821
* Pass to emit DWARF path discriminators.Diego Novillo2014-03-031-1/+6
| | | | | | | | | | | | | | | | DWARF discriminators are used to distinguish multiple control flow paths on the same source location. When this happens, instructions across basic block boundaries will share the same debug location. This pass detects this situation and creates a new lexical scope to one of the two instructions. This lexical scope is a child scope of the original and contains a new discriminator value. This discriminator is then picked up from MCObjectStreamer::EmitDwarfLocDirective to be written on the object file. This fixes http://llvm.org/bugs/show_bug.cgi?id=18270. llvm-svn: 202752
* Add a const lookup routine to get a BlockAddress constant if there isChandler Carruth2014-01-191-2/+2
| | | | | | | | one, but not create one. This is useful in the verifier when we want to query the constant if it exists but not create one. To be used in an upcoming commit. llvm-svn: 199568
* Add warning capabilities in LLVM.Quentin Colombet2013-12-171-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> llvm-svn: 197508
* Revert r197438 and r197447 until we figure out how to avoid circular ↵Quentin Colombet2013-12-171-6/+3
| | | | | | dependency at link time llvm-svn: 197451
* Add warning capabilities in LLVM.Quentin Colombet2013-12-161-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> llvm-svn: 197438
* Implement function prefix data as an IR feature.Peter Collingbourne2013-09-161-0/+5
| | | | | | | | | Previous discussion: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063909.html Differential Revision: http://llvm-reviews.chandlerc.com/D1191 llvm-svn: 190773
* Revert "Give internal classes hidden visibility."Benjamin Kramer2013-09-111-6/+6
| | | | | | | It works with clang, but GCC has different rules so we can't make all of those hidden. This reverts commit r190534. llvm-svn: 190536
* Give internal classes hidden visibility.Benjamin Kramer2013-09-111-6/+6
| | | | | | Worth 100k on a linux/x86_64 Release+Asserts clang. llvm-svn: 190534
* Cache the result of Function::getIntrinsicID() in a DenseMap attached to the ↵Michael Ilseman2013-03-011-1/+6
| | | | | | | | | | LLVMContext. This reduces the time actually spent doing string to ID conversion and shows a 10% improvement in compile time for a particularly bad case that involves ARM Neon intrinsics (these have many overloads). Patch by Jean-Luc Duprat! llvm-svn: 176365
* Revert "Rename LLVMContext diagnostic handler types and functions."Bob Wilson2013-02-111-2/+2
| | | | | | | | | 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. llvm-svn: 174860
* Create a new class: AttributeSetNode.Bill Wendling2013-01-241-0/+1
| | | | | | | | | | This is a helper class for the AttributeSetImpl class. It holds a set of attributes that apply to a single element: function, return type, or parameter. These are uniqued. llvm-svn: 173310
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-4/+4
| | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 171366
* Rename VMCore directory to IR.Chandler Carruth2013-01-021-0/+361
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) llvm-svn: 171359
OpenPOWER on IntegriCloud