summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode/Writer/ValueEnumerator.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* BitcodeWriter: Stop using implicit ilist iterator conversion, NFCDuncan P. N. Exon Smith2015-10-131-25/+19
| | | | | | | | | | Now LLVMBitWriter compiles without implicit ilist iterator conversions. In these cases, the cleanest thing was to switch to range-based for loops. Since there wasn't much noise I converted sub-loops and parent loops as a drive-by. llvm-svn: 250144
* Use foreach loop over constant operands. NFC.Pete Cooper2015-06-251-3/+1
| | | | | | | A number of places had explicit loops over Constant::operands(). Just use foreach loops where possible. llvm-svn: 240694
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-231-1/+1
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-191-1/+1
| | | | | | | | | | | | | The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-171-0/+10
| | | | | | | | | | | | | | | | | | | The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
* Rangify several for loops in ValueEnumerator constructor.Yaron Keren2015-06-121-22/+18
| | | | llvm-svn: 239636
* IR: Give 'DI' prefix to debug info metadataDuncan P. N. Exon Smith2015-04-291-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
* IR: Add assembly/bitcode support for function metadata attachmentsDuncan P. N. Exon Smith2015-04-241-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add serialization support for function metadata attachments (added in r235783). The syntax is: define @foo() !attach !0 { Metadata attachments are only allowed on functions with bodies. Since they come before the `{`, they're not really part of the body; since they require a body, they're not really part of the header. In `LLParser` I gave them a separate function called from `ParseDefine()`, `ParseOptionalFunctionMetadata()`. In bitcode, I'm using the same `METADATA_ATTACHMENT` record used by instructions. Instruction metadata attachments are included in a special "attachment" block at the end of a `Function`. The attachment records are laid out like this: InstID (KindID MetadataID)+ Note that these records always have an odd number of fields. The new code takes advantage of this to recognize function attachments (which don't need an instruction ID): (KindID MetadataID)+ This means we can use the same attachment block already used for instructions. This is part of PR23340. llvm-svn: 235785
* uselistorder: Thread bit through ValueEnumeratorDuncan P. N. Exon Smith2015-04-141-4/+6
| | | | | | | | Canonicalize access to whether to preserve use-list order in bitcode on a `bool` stored in `ValueEnumerator`. Next step, expose this as a `bool` through `WriteBitcodeToFile()`. llvm-svn: 234956
* IR: Use the new DebugLoc API, NFCDuncan P. N. Exon Smith2015-03-301-6/+4
| | | | | | | | Update lib/IR and lib/Bitcode to use the new `DebugLoc` API. Added an explicit conversion to `bool` (avoiding a conversion to `MDLocation`), since a couple of these use cases need to handle broken code. llvm-svn: 233585
* BitcodeWriter: Refactor common computation of bits required for a type index.David Blaikie2015-02-251-0/+4
| | | | | | Suggested by Duncan. Happy to bikeshed the name, cache the result, etc. llvm-svn: 230410
* IR: Assembly and bitcode for GenericDebugNodeDuncan P. N. Exon Smith2015-02-031-1/+2
| | | | llvm-svn: 228041
* IR: Split out DebugInfoMetadata.h, NFCDuncan P. N. Exon Smith2015-02-021-0/+1
| | | | | | | | | Move debug-info-centred `Metadata` subclasses into their own header/source file. A couple of private template functions are needed from both `Metadata.cpp` and `DebugInfoMetadata.cpp`, so I've moved them to `lib/IR/MetadataImpl.h`. llvm-svn: 227835
* Bitcode: Add ValueEnumerator::getMetadataOrNullID(), NFCDuncan P. N. Exon Smith2015-01-201-6/+0
| | | | llvm-svn: 226533
* AsmParser/Bitcode: Add support for MDLocationDuncan P. N. Exon Smith2015-01-131-1/+3
| | | | | | | | | | | | This adds assembly and bitcode support for `MDLocation`. The assembly side is rather big, since this is the first `MDNode` subclass (that isn't `MDTuple`). Part of PR21433. (If you're wondering where the mountains of testcase updates are, we don't need them until I update `DILocation` and `DebugLoc` to actually use this class.) llvm-svn: 225830
* Bitcode: Simplify emission of METADATA_BLOCKDuncan P. N. Exon Smith2015-01-121-1/+3
| | | | | | | | | | Refactor logic so that we know up-front whether to open a block and whether we need an MDString abbreviation. This is almost NFC, but will start emitting `MDString` abbreviations when the first record is not an `MDString`. llvm-svn: 225712
* Make ValueEnumerator::print use OS for metadata too. Noticed by inspection.Nick Lewycky2014-12-171-2/+1
| | | | llvm-svn: 224404
* Bitcode: Add METADATA_NODE and METADATA_VALUEDuncan P. N. Exon Smith2014-12-111-7/+1
| | | | | | | | | | | | | | | | 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. llvm-svn: 224073
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-091-93/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Prologue supportPeter Collingbourne2014-12-031-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add and use Type::subtypes. NFC.Rafael Espindola2014-11-241-3/+2
| | | | llvm-svn: 222682
* Pass a reference to ValueEnumerator.Rafael Espindola2014-11-171-34/+33
| | | | | | NFC. This will just make it easier to use std::unique_ptr in a caller. llvm-svn: 222170
* Revert "IR: MDNode => Value"Duncan P. N. Exon Smith2014-11-111-4/+4
| | | | | | | | | | | | | | | | | 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. llvm-svn: 221711
* IR: MDNode => Value: Instruction::getAllMetadataOtherThanDebugLoc()Duncan P. N. Exon Smith2014-11-031-4/+4
| | | | | | | Change `Instruction::getAllMetadataOtherThanDebugLoc()` from a vector of `MDNode` to one of `Value`. Part of PR21433. llvm-svn: 221167
* IR: Reorder metadata bitcode serialization, NFCDuncan P. N. Exon Smith2014-10-211-12/+14
| | | | | | | | | 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. llvm-svn: 220340
* IR: Remove dead code in metadata bitcode writing, NFCDuncan P. N. Exon Smith2014-10-211-11/+7
| | | | | | | No one cares how many uses each metadata value has, so don't bother counting. llvm-svn: 220337
* UseListOrder: Handle self-usersDuncan P. N. Exon Smith2014-07-311-3/+3
| | | | | | | | | | 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. llvm-svn: 214417
* UseListOrder: Don't give constant IDs to GlobalValuesDuncan P. N. Exon Smith2014-07-311-3/+6
| | | | | | | | | | | 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. llvm-svn: 214368
* UseListOrder: Visit global valuesDuncan P. N. Exon Smith2014-07-301-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When predicting use-list order, we visit functions in reverse order followed by `GlobalValue`s and write out use-lists at the first opportunity. In the reader, this will translate to *after* the last use has been added. For this to work, we actually need to descend into `GlobalValue`s. Added a targeted test in `use-list-order.ll` and `RUN` lines to the newly passing tests in `test/Bitcode`. There are two remaining failures in `test/Bitcode`: - blockaddress.ll: I haven't thought through how to model the way block addresses change the order of use-lists (or how to work around it). - metadata-2.ll: There's an old-style `@llvm.used` global array here that I suspect the .ll parser isn't upgrading properly. When it round-trips through bitcode, the .bc reader *does* upgrade it, so the extra variable (`i8* null`) has an extra use, and the shuffle vector doesn't match. I think the fix is to upgrade old-style global arrays (or reject them?) in the .ll parser. This is part of PR5680. llvm-svn: 214321
* Reapply "UseListOrder: Order GlobalValue uses after initializers"Duncan P. N. Exon Smith2014-07-301-14/+55
| | | | | | | This reverts commit r214249, reapplying r214242 and r214243, now that r214270 has fixed the UB. llvm-svn: 214271
* UseListOrder: Fix undefined behaviourDuncan P. N. Exon Smith2014-07-301-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes undefined behaviour that caused the revert in r214249. The problem was two unsequenced operations on a `DenseMap<>`, giving different behaviour in GCC and Clang. This: DenseMap<T*, unsigned> DM; for (auto &X : ...) DM[&X] = DM.size() + 1; should have been: DenseMap<T*, unsigned> DM; for (auto &X : ...) { unsigned Size = DM.size(); DM[&X] = Size + 1; } Until r214242, this difference between compilers didn't matter. In r214242, `OrderMap::LastGlobalValueID` was introduced and compared against IDs, which in GCC were off-by-one my expectations. llvm-svn: 214270
* Revert "UseListOrder: Order GlobalValue uses after initializers"Duncan P. N. Exon Smith2014-07-291-55/+14
| | | | | | | | | | | | This reverts commits r214242 and r214243 while I investigate buildbot failures [1][2][3]. I can't reproduce these failures locally, so if anyone can see what I've done wrong, I'd appreciate a note. [1]: http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/9840 [2]: http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/14981 [3]: http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/15191 llvm-svn: 214249
* UseListOrder: Order GlobalValue uses after initializersDuncan P. N. Exon Smith2014-07-291-14/+55
| | | | | | | | | | | | To avoid unnecessary forward references, the reader doesn't process initializers of `GlobalValue`s until after the constant pool has been processed, and then in reverse order. Model this when predicting use-list order. This gets two more Bitcode tests passing with `llvm-uselistorder`. Part of PR5680. llvm-svn: 214242
* UseListOrder: Create a struct around OrderMap, NFCDuncan P. N. Exon Smith2014-07-291-1/+9
| | | | llvm-svn: 214241
* IR: Create the use-list order shuffle vector in-placeDuncan P. N. Exon Smith2014-07-291-4/+3
| | | | | | | Per David Blaikie's review of r214135, this is a more natural way to initialize. llvm-svn: 214184
* Bitcode: Correctly compare a Use against itselfDuncan P. N. Exon Smith2014-07-291-0/+3
| | | | | | | | | | | | | | | Fix the sort of expected order in the reader to correctly return `false` when comparing a `Use` against itself. This was caught by test/Bitcode/binaryIntInstructions.3.2.ll, so I'm adding a `RUN` line using `llvm-uselistorder` for every test in `test/Bitcode` that passes. A few tests still fail, so I'll investigate those next. This is part of PR5680. llvm-svn: 214157
* IR: Optimize size of use-list order shuffle vectorsDuncan P. N. Exon Smith2014-07-281-6/+5
| | | | | | | | | Since we're storing lots of these, save two-pointers per vector with a custom type rather than using the relatively heavy `SmallVector`. Part of PR5680. llvm-svn: 214135
* Bitcode: Serialize (and recover) use-list orderDuncan P. N. Exon Smith2014-07-281-0/+193
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Predict and serialize use-list order in bitcode. This makes the option `-preserve-bc-use-list-order` work *most* of the time, but this is still experimental. - Builds a full value-table up front in the writer, sets up a list of use-list orders to write out, and discards the table. This is a simpler first step than determining the order from the various overlapping IDs of values on-the-fly. - The shuffles stored in the use-list order list have an unnecessarily large memory footprint. - `blockaddress` expressions cause functions to be materialized out-of-order. For now I've ignored this problem, so use-list orders will be wrong for constants used by functions that have block addresses taken. There are a couple of ways to fix this, but I don't have a concrete plan yet. - When materializing functions lazily, the use-lists for constants will not be correct. This use case is out of scope: what should the use-list order be, if it's incomplete? This is part of PR5680. llvm-svn: 214125
* Bitcode: Don't optimize constants when preserving use-list orderDuncan P. N. Exon Smith2014-07-251-0/+6
| | | | | | | | | | | | | | | | | | | | `ValueEnumerator::OptimizeConstants()` creates forward references within the constant pools, which makes predicting constants' use-list order difficult. For now, just disable the optimization. This can be re-enabled in the future in one of two ways: - Enable a limited version of this optimization that doesn't create forward references. One idea is to categorize constants by their "height" and make that the top-level sort. - Enable it entirely. This requires predicting how may times each constant will be recreated as its operands' and operands' operands' (etc.) forward references get resolved. This is part of PR5680. llvm-svn: 213953
* IR: Add COMDATs to the IRDavid Majnemer2014-06-271-0/+10
| | | | | | | | | | | | | | | | This new IR facility allows us to represent the object-file semantic of a COMDAT group. COMDATs allow us to tie together sections and make the inclusion of one dependent on another. This is required to implement features like MS ABI VFTables and optimizing away certain kinds of initialization in C++. This functionality is only representable in COFF and ELF, Mach-O has no similar mechanism. Differential Revision: http://reviews.llvm.org/D4178 llvm-svn: 211920
* Convert a few loops to use ranges.Rafael Espindola2014-06-171-18/+15
| | | | llvm-svn: 211089
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-091-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
* Now that we have C++11, turn simple functors into lambdas and remove a ton ↵Benjamin Kramer2014-03-011-19/+9
| | | | | | | | of boilerplate. No intended functionality change. llvm-svn: 202588
* 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
* Whitespace cleanupJoe Abbey2013-04-011-1/+1
| | | | llvm-svn: 178454
* Use the AttributeSet as the 'key' to the map instead of the 'raw' pointer.Bill Wendling2013-02-121-2/+3
| | | | llvm-svn: 174950
* Rename AttributeSets to AttributeGroups so that it's more meaningful.Bill Wendling2013-02-111-3/+3
| | | | llvm-svn: 174911
* Add support for attribute groups in the value enumerator.Bill Wendling2013-02-101-0/+10
| | | | | | | Attribute groups are essentially all AttributeSets which are used by the program. Enumerate them here. llvm-svn: 174844
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-5/+5
| | | | | | | | | | | | | | | | | | | | | 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 the 'Attributes' class to 'Attribute'. It's going to represent a ↵Bill Wendling2012-12-191-2/+2
| | | | | | single attribute in the future. llvm-svn: 170502
OpenPOWER on IntegriCloud