summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode/Writer/ValueEnumerator.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* s/AttrListPtr/AttributeSet/g to better label what this class is going to be ↵Bill Wendling2012-12-071-1/+1
| | | | | | in the near future. llvm-svn: 169651
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-3/+3
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Code Custodian:Joe Abbey2012-11-251-10/+10
| | | | | | | | - Widespread trailing space removal - A dash of OCD spacing to block align enums - joined a line that probably needed 80 cols a while back llvm-svn: 168566
* Relax the restrictions on vector of pointer types, and vector getelementptr.Duncan Sands2012-11-131-5/+6
| | | | | | | | | | | | | | | Previously in a vector of pointers, the pointer couldn't be any pointer type, it had to be a pointer to an integer or floating point type. This is a hassle for dragonegg because the GCC vectorizer happily produces vectors of pointers where the pointer is a pointer to a struct or whatever. Vector getelementptr was restricted to just one index, but now that vectors of pointers can have any pointer type it is more natural to allow arbitrary vector getelementptrs. There is however the issue of struct GEPs, where if each lane chose different struct fields then from that point on each lane will be working down into unrelated types. This seems like too much pain for too little gain, so when you have a vector struct index all the elements are required to be the same. llvm-svn: 167828
* reapply the patches reverted in r149470 that reenable ConstantDataArray,Chris Lattner2012-02-051-4/+0
| | | | | | | | | but with a critical fix to the SelectionDAG code that optimizes copies from strings into immediate stores: the previous code was stopping reading string data at the first nul. Address this by adding a new argument to llvm::getConstantStringInfo, preserving the behavior before the patch. llvm-svn: 149800
* Revert Chris' commits up to r149348 that started causing VMCoreTests unit ↵Argyrios Kyrtzidis2012-02-011-0/+4
| | | | | | | | | | | | | | | | | | | test to fail. These are: r149348 r149351 r149352 r149354 r149356 r149357 r149361 r149362 r149364 r149365 llvm-svn: 149470
* with recent changes, ConstantArray is never a "string". Remove the associatedChris Lattner2012-01-311-4/+0
| | | | | | methods and constant fold the clients to false. llvm-svn: 149362
* ValueEnumerator - debug dump().Chad Rosier2011-12-071-1/+39
| | | | llvm-svn: 146070
* switch to use the new api for structtypes.Chris Lattner2011-08-121-1/+1
| | | | llvm-svn: 137480
* land David Blaikie's patch to de-constify Type, with a few tweaks.Chris Lattner2011-07-181-2/+2
| | | | llvm-svn: 135375
* Land the long talked about "type system rewrite" patch. ThisChris Lattner2011-07-091-86/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | patch brings numerous advantages to LLVM. One way to look at it is through diffstat: 109 files changed, 3005 insertions(+), 5906 deletions(-) Removing almost 3K lines of code is a good thing. Other advantages include: 1. Value::getType() is a simple load that can be CSE'd, not a mutating union-find operation. 2. Types a uniqued and never move once created, defining away PATypeHolder. 3. Structs can be "named" now, and their name is part of the identity that uniques them. This means that the compiler doesn't merge them structurally which makes the IR much less confusing. 4. Now that there is no way to get a cycle in a type graph without a named struct type, "upreferences" go away. 5. Type refinement is completely gone, which should make LTO much MUCH faster in some common cases with C++ code. 6. Types are now generally immutable, so we can use "Type *" instead "const Type *" everywhere. Downsides of this patch are that it removes some functions from the C API, so people using those will have to upgrade to (not yet added) new API. "LLVM 3.0" is the right time to do this. There are still some cleanups pending after this, this patch is large enough as-is. llvm-svn: 134829
* Revert name change from r132533. Lower case naming was intended per style ↵Chad Rosier2011-06-031-2/+2
| | | | | | guidelines. llvm-svn: 132555
* Whitespace and other cleanup. Functionallity unchanged.Chad Rosier2011-06-031-3/+2
| | | | llvm-svn: 132533
* Fix a ton of comment typos found by codespell. Patch byChris Lattner2011-04-151-1/+1
| | | | | | Luis Felipe Strano Moraes! llvm-svn: 129558
* Fix or remove code which seemed to think that the operand of a ConstantJay Foad2011-04-111-1/+1
| | | | | | was always a User. llvm-svn: 129272
* Do a topological sort of the types before writing them out.Rafael Espindola2011-04-061-26/+68
| | | | | | This takes the linking of libxul on linux from 6m54.931s to 5m39.840s. llvm-svn: 129009
* Clear FunctionLocalMDs in purgeFunction along with the rest of theDan Gohman2010-08-251-1/+1
| | | | | | function-specific state. llvm-svn: 112058
* Fix whitespace.Dan Gohman2010-08-251-1/+1
| | | | llvm-svn: 112056
* Eliminate an unnecessary cast.Dan Gohman2010-08-251-1/+1
| | | | llvm-svn: 112055
* Add braces to fix dangling else.Dan Gohman2010-08-241-2/+2
| | | | llvm-svn: 111896
* Extend function-local metadata to be usable as attachments.Dan Gohman2010-08-241-20/+77
| | | | llvm-svn: 111895
* When we know we have an MDValue or MDString, call EnumerateMetadataDan Gohman2010-08-241-1/+1
| | | | | | directly instead of going through EnumerateValue. llvm-svn: 111894
* Simplify this code. NamedMDNode operands are MDNodes.Dan Gohman2010-08-241-2/+1
| | | | llvm-svn: 111892
* Make NamedMDNode not be a subclass of Value, and simplify the interfaceDan Gohman2010-07-211-22/+7
| | | | | | for creating and populating NamedMDNodes. llvm-svn: 109061
* Fix whitespace.Dan Gohman2010-07-161-2/+2
| | | | llvm-svn: 108569
* Tidy.Bob Wilson2010-06-191-1/+1
| | | | llvm-svn: 106383
OpenPOWER on IntegriCloud