summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Bitcode/Writer/ValueEnumerator.cpp
Commit message (Collapse)AuthorAgeFilesLines
* IR: make getParamByValType Just Work. NFC.Tim Northover2019-06-051-1/+1
| | | | | | | | | | | Most parts of LLVM don't care whether the byval type is derived from an explicit Attribute or from the parameter's pointee type, so it makes sense for the main access function to just return the right value. The very few users who do care (only BitcodeReader so far) can find out how it's specified by accessing the Attribute directly. llvm-svn: 362642
* Reapply: IR: add optional type to 'byval' function parametersTim Northover2019-05-301-2/+4
| | | | | | | | | | | | | | | | | When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
* Revert "IR: add optional type to 'byval' function parameters"Tim Northover2019-05-291-4/+2
| | | | | | | The IRLinker doesn't delve into the new byval attribute when mapping types, and this breaks LTO. llvm-svn: 362029
* IR: add optional type to 'byval' function parametersTim Northover2019-05-291-2/+4
| | | | | | | | | | | | | | When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362012
* Avoid use-after-move warnings by using swap instead. NFCI.Simon Pilgrim2019-05-071-1/+2
| | | | | | Swap should be as quick in these cases, and leaves the original variables in a known (empty) state. llvm-svn: 360164
* Implementation of asm-goto support in LLVMCraig Topper2019-02-081-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This patch accompanies the RFC posted here: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html This patch adds a new CallBr IR instruction to support asm-goto inline assembly like gcc as used by the linux kernel. This instruction is both a call instruction and a terminator instruction with multiple successors. Only inline assembly usage is supported today. This also adds a new INLINEASM_BR opcode to SelectionDAG and MachineIR to represent an INLINEASM block that is also considered a terminator instruction. There will likely be more bug fixes and optimizations to follow this, but we felt it had reached a point where we would like to switch to an incremental development model. Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii Differential Revision: https://reviews.llvm.org/D53765 llvm-svn: 353563
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-271-2/+2
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* [STLExtras] Add distance() for ranges, pred_size(), and succ_size()Vedant Kumar2018-05-101-1/+1
| | | | | | | | | | | This commit adds a wrapper for std::distance() which works with ranges. As it would be a common case to write `distance(predecessors(BB))`, this also introduces `pred_size()` and `succ_size()` helpers to make that easier to write. Differential Revision: https://reviews.llvm.org/D46668 llvm-svn: 332057
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* [Bitcode] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches. Reviewers: pcc, mehdi_amini, dexonsmith Reviewed By: dexonsmith Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45132 llvm-svn: 329334
* Reverting r315590; it did not include changes for llvm-tblgen, which is ↵Aaron Ballman2017-10-151-1/+1
| | | | | | | | causing link errors for several people. Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::MatchableInfo::dump(void)const " (?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function "public: void __cdecl `anonymous namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)" (?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@Z) llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1 llvm-svn: 315854
* [dump] Remove NDEBUG from test to enable dump methods [NFC]Don Hinton2017-10-121-1/+1
| | | | | | | | | | | | | | | Summary: Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP. Remove NDEBUG and only use LLVM_ENABLE_DUMP to enable dump methods. Move definition of LLVM_ENABLE_DUMP from config.h to llvm-config.h so it'll be picked up by public headers. Differential Revision: https://reviews.llvm.org/D38406 llvm-svn: 315590
* [Bitcode] Fix some Clang-tidy modernize-use-using and Include What You Use ↵Eugene Zelenko2017-09-071-13/+39
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 312760
* [IR] Switch AttributeList to use an array for O(1) accessReid Kleckner2017-05-231-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
* [IR] Allow attributes with global variablesJaved Absar2017-05-111-2/+5
| | | | | | | | | | | | | This patch extends llvm-ir to allow attributes to be set on global variables. An RFC was sent out earlier by my colleague James Molloy: http://lists.llvm.org/pipermail/cfe-dev/2017-March/053100.html A key part of that proposal was to extend LLVM-IR to carry attributes on global variables. This generic feature could be useful for multiple purposes. In our present context, it would be useful to carry user specified sections for bss/rodata/data. Reviewed by: Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D32009 llvm-svn: 302794
* Make getSlotAttributes return an AttributeSet instead of a wrapper listReid Kleckner2017-04-241-1/+1
| | | | | | | | Remove the temporary, poorly named getSlotSet method which did the same thing. Also remove getSlotNode, which is a hold-over from when we were dealing with AttributeSetNode* instead of AttributeSet. llvm-svn: 301267
* [Bitcode] Refactor attribute group writing to avoid getSlotAttributesReid Kleckner2017-04-241-6/+6
| | | | | | | | | | | | | | | | | Summary: That API creates a temporary AttributeList to carry an index and a single AttributeSet. We need to carry the index in addition to the set, because that is how attribute groups are currently encoded. NFC Reviewers: pcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32262 llvm-svn: 301245
* Rename AttributeSet to AttributeListReid Kleckner2017-03-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
* Cleanup dump() functions.Matthias Braun2017-01-281-1/+4
| | | | | | | | | | | | | | | | | | We had various variants of defining dump() functions in LLVM. Normalize them (this should just consistently implement the things discussed in http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html For reference: - Public headers should just declare the dump() method but not use LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) - The definition of a dump method should look like this: #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) LLVM_DUMP_METHOD void MyClass::dump() { // print stuff to dbgs()... } #endif llvm-svn: 293359
* Remove unused lambda captures. NFCMalcolm Parsons2017-01-131-1/+1
| | | | llvm-svn: 291916
* Add an assertion for the value enumerator (bitcode writer) NFCMehdi Amini2016-07-081-1/+6
| | | | | | | | I have an LTO snapshot (for which I don't have sources) that can't be read back by LLVM. It seems the writer emitted broken bitcode and this assertions aims at catching such cases. llvm-svn: 274819
* IR: Allow metadata attachments on declarations, and fix lazy loaded metadata ↵Peter Collingbourne2016-06-211-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | issue with globals. This change is motivated by an upcoming change to the metadata representation used for CFI. The indirect function call checker needs type information for external function declarations in order to correctly generate jump table entries for such declarations. We currently associate such type information with declarations using a global metadata node, but I plan [1] to move all such metadata to global object attachments. In bitcode, metadata attachments for function declarations appear in the global metadata block. This seems reasonable to me because I expect metadata attachments on declarations to be uncommon. In the long term I'd also expect this to be the case for CFI, because we'd want to use some specialized bitcode format for this metadata that could be read as part of the ThinLTO thin-link phase, which would mean that it would not appear in the global metadata block. To solve the lazy loaded metadata issue I was seeing with D20147, I use the same bitcode representation for metadata attachments for global variables as I do for function declarations. Since there's a use case for metadata attachments in the global metadata block, we might as well use that representation for global variables as well, at least until we have a mechanism for lazy loading global variables. In the assembly format, the metadata attachments appear after the "declare" keyword in order to avoid a parsing ambiguity. [1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html Differential Revision: http://reviews.llvm.org/D21052 llvm-svn: 273336
* IR: Allow multiple global metadata attachments with the same type.Peter Collingbourne2016-06-011-0/+2
| | | | | | | | | | This will be necessary to allow the global merge pass to attach multiple debug info metadata nodes to global variables once we reverse the edge from DIGlobalVariable to GlobalVariable. Differential Revision: http://reviews.llvm.org/D20414 llvm-svn: 271358
* Add support for metadata attachments for global variables.Peter Collingbourne2016-05-311-5/+11
| | | | | | | | | | This patch adds an IR, assembly and bitcode representation for metadata attachments for globals. Future patches will port existing features to use these new attachments. Differential Revision: http://reviews.llvm.org/D20074 llvm-svn: 271348
* BitcodeWriter: Emit uniqued subgraphs after all distinct nodesDuncan P. N. Exon Smith2016-04-231-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since forward references for uniqued node operands are expensive (and those for distinct node operands are cheap due to DistinctMDOperandPlaceholder), minimize forward references in uniqued node operands. Moreover, guarantee that when a cycle is broken by a distinct node, none of the uniqued nodes have any forward references. In ValueEnumerator::EnumerateMetadata, enumerate uniqued node subgraphs first, delaying distinct nodes until all uniqued nodes have been handled. This guarantees that uniqued nodes only have forward references when there is a uniquing cycle (since r267276 changed ValueEnumerator::organizeMetadata to partition distinct nodes in front of uniqued nodes as a post-pass). Note that a single uniqued subgraph can hit multiple distinct nodes at its leaves. Ideally these would themselves be emitted in post-order, but this commit doesn't attempt that; I think it requires an extra pass through the edges, which I'm not convinced is worth it (since DistinctMDOperandPlaceholder makes forward references quite cheap between distinct nodes). I've added two testcases: - test/Bitcode/mdnodes-distinct-in-post-order.ll is just like test/Bitcode/mdnodes-in-post-order.ll, except with distinct nodes instead of uniqued ones. This confirms that, in the absence of uniqued nodes, distinct nodes are still emitted in post-order. - test/Bitcode/mdnodes-distinct-nodes-break-cycles.ll is the minimal example where a naive post-order traversal would cause one uniqued node to forward-reference another. IOW, it's the motivating test. llvm-svn: 267278
* BitcodeWriter: Emit distinct nodes before uniqued nodesDuncan P. N. Exon Smith2016-04-231-6/+18
| | | | | | | | | | | | | | | When an operand of a distinct node hasn't been read yet, the reader can use a DistinctMDOperandPlaceholder. This is much cheaper than forward referencing from a uniqued node. Change ValueEnumerator::organizeMetadata to partition distinct nodes and uniqued nodes to reduce the overhead of cycles broken by distinct nodes. Mehdi measured this for me; this removes most of the RAUW from the importing step of -flto=thin, even after a WIP patch that removes string-based DITypeRefs (introducing many more cycles to the metadata graph). llvm-svn: 267276
* ValueEnumerator: Use std::find_if, NFCDuncan P. N. Exon Smith2016-04-231-13/+8
| | | | | | | | Mehdi's pattern recognition pulled this one out. This is cleaner with std::find_if than with the strange helper function that took an iterator by reference and updated it. llvm-svn: 267271
* ValueMapper/Enumerator: Clean up code in post-order traversals, NFCDuncan P. N. Exon Smith2016-04-221-22/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Re-layer the functions in the new (i.e., newly correct) post-order traversals in ValueEnumerator (r266947) and ValueMapper (r266949). Instead of adding a node to the worklist in a helper function and returning a flag to say what happened, return the node itself. This makes the code way cleaner: the worklist is local to the main function, there is no flag for an early loop exit (since we can cleanly bury the loop), and it's perfectly clear when pointers into the worklist might be invalidated. I'm fixing both algorithms in the same commit to avoid repeating the commit message; if you take the time to understand one the other should be easy. The diff itself isn't entirely obvious since the traversals have some noise (i.e., things to do), but here's the high-level change: auto helper = [&WL](T *Op) { auto helper = [](T **&I, T **E) { => while (I != E) { if (shouldVisit(Op)) { T *Op = *I++; WL.push(Op, Op->begin()); if (shouldVisit(Op)) { return true; return Op; } } return false; return nullptr; }; }; => WL.push(S, S->begin()); WL.push(S, S->begin()); while (!empty()) { while (!empty()) { auto *N = WL.top().N; auto *N = WL.top().N; auto *&I = WL.top().I; auto *&I = WL.top().I; bool DidChange = false; while (I != N->end()) if (helper(*I++)) { => if (T *Op = helper(I, N->end()) { DidChange = true; WL.push(Op, Op->begin()); break; continue; } } if (DidChange) continue; POT.push(WL.pop()); => POT.push(WL.pop()); } } Thanks to Mehdi for helping me find a better way to layer this. llvm-svn: 267099
* BitcodeWriter: Emit metadata in post-order (again)Duncan P. N. Exon Smith2016-04-211-15/+21
| | | | | | | | | | | | | | | Emit metadata nodes in post-order. The iterative algorithm from r266709 failed to maintain this property. After understanding my mistake, it wasn't too hard to write a test with llvm-bcanalyzer (and I've actually made this change once before: see r220340). This also reverts the "noisy" testcase change from r266709. That should have been more of a red flag :/. Note: The same bug crept into the ValueMapper in r265456. I'm still working on the fix. llvm-svn: 266947
* BitcodeWriter: Break recursion when enumerating Metadata, almost NFCDuncan P. N. Exon Smith2016-04-191-67/+69
| | | | | | | | | | | Use a worklist instead of recursing through MDNode operands in ValueEnumerator. The actual record output order has changed slightly, but otherwise there's no functionality change. I had to update test/Bitcode/metadata-function-blocks.ll. I renumbered nodes so they continue to match the implicit record ids. llvm-svn: 266709
* BitcodeWriter: WorkList => Worklist, NFCDuncan P. N. Exon Smith2016-04-181-5/+5
| | | | | | | | I have no idea how I chose two different spellings in the space of a couple of weeks, but now I can't remember what to use where. Choose "Worklist". llvm-svn: 266582
* [GCC] Attribute ifunc support in llvmDmitry Polukhin2016-04-071-0/+17
| | | | | | | | | | | This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. Patch for Clang http://reviews.llvm.org/D15524 Differential Revision: http://reviews.llvm.org/D15525 llvm-svn: 265667
* Bitcode: Try to emit metadata in function blocksDuncan P. N. Exon Smith2016-04-021-30/+171
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Whenever metadata is only referenced by a single function, emit the metadata just in that function block. This should improve lazy-loading by reducing the amount of metadata in the global block. For now, this should catch all DILocations, and anything else that happens to be referenced only by a single function. It's also a first step toward a couple of possible future directions (which this commit does *not* implement): 1. Some debug info metadata is only referenced from compile units and individual functions. If we can drop the link from the compile unit, this optimization will get more powerful. 2. Any uniqued metadata that isn't referenced globally can in theory be emitted in every function block that references it (trading off bitcode size and full-parse time vs. lazy-load time). Note: this assumes the new BitcodeReader error checking from r265223. The metadata stored in function blocks gets purged after parsing each function, which means unresolved forward references will get lost. Since all the global metadata should have already been resolved by the time we get to the function metadata blocks we just need to check for that case. (If for some reason we need to handle bitcode that fails the checks in r265223, the fix is to store about-to-be-dropped unresolved nodes in MetadataList::shrinkTo until they can be handled succesfully by a future call to MetadataList::tryToResolveCycles.) llvm-svn: 265226
* BitcodeWriter: Further unify function metadata, NFCDuncan P. N. Exon Smith2016-04-021-0/+1
| | | | | | | | | | | | | Further unify the handling of function-local metadata with global metadata, by exposing the same interface in ValueEnumerator. Both contexts use the same accessors: - getMDStrings(): get the strings for this block. - getNonMDStrings(): get the non-strings for this block. A future commit will start adding strings to the function-block. llvm-svn: 265224
* BitcodeWriter: Replace dead code with an assertion, NFCDuncan P. N. Exon Smith2016-03-281-7/+1
| | | | | | | The caller of ValueEnumerator::EnumerateOperandType never sends in metadata. Assert that, and remove the unnecessary logic. llvm-svn: 264558
* BitcodeWriter: Simplify tracking of function-local metadata, NFCDuncan P. N. Exon Smith2016-03-271-4/+0
| | | | | | | | We don't really need a separate vector here; instead, point at a range inside the main MDs array. This matches how r264551 references the ranges of strings and non-strings. llvm-svn: 264552
* Reapply ~"Bitcode: Collect all MDString records into a single blob"Duncan P. N. Exon Smith2016-03-271-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Spiritually reapply commit r264409 (reverted in r264410), albeit with a bit of a redesign. Firstly, avoid splitting the big blob into multiple chunks of strings. r264409 imposed an arbitrary limit to avoid a massive allocation on the shared 'Record' SmallVector. The bug with that commit only reproduced when there were more than "chunk-size" strings. A test for this would have been useless long-term, since we're liable to adjust the chunk-size in the future. Thus, eliminate the motivation for chunk-ing by storing the string sizes in the blob. Here's the layout: vbr6: # of strings vbr6: offset-to-blob blob: [vbr6]: string lengths [char]: concatenated strings Secondly, make the output of llvm-bcanalyzer readable. I noticed when debugging r264409 that llvm-bcanalyzer was outputting a massive blob all in one line. Past a small number, the strings were impossible to split in my head, and the lines were way too long. This version adds support in llvm-bcanalyzer for pretty-printing. <STRINGS abbrevid=4 op0=3 op1=9/> num-strings = 3 { 'abc' 'def' 'ghi' } From the original commit: Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this should (a) slightly reduce bitcode size, since there is less record overhead, and (b) greatly improve reading speed, since blobs are super cheap to deserialize. llvm-svn: 264551
* Revert "Bitcode: Collect all MDString records into a single blob"Duncan P. N. Exon Smith2016-03-251-19/+4
| | | | | | | This reverts commit r264409 since it failed to bootstrap: http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/8302/ llvm-svn: 264410
* Bitcode: Collect all MDString records into a single blobDuncan P. N. Exon Smith2016-03-251-4/+19
| | | | | | | | | | | | | | | | | | | | | | | Optimize output of MDStrings in bitcode. This emits them in big blocks (currently 1024) in a pair of records: - BULK_STRING_SIZES: the sizes of the strings in the block, and - BULK_STRING_DATA: a single blob, which is the concatenation of all the strings. Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this should (a) slightly reduce bitcode size, since there is less record overhead, and (b) greatly improve reading speed, since blobs are super cheap to deserialize. I needed to add support for blobs to streaming input to get the test suite passing. - StreamingMemoryObject::getPointer reads ahead and returns the address of the blob. - To avoid a possible reallocation of StreamingMemoryObject::Bytes, BitstreamCursor::readRecord needs to move the call to JumpToEnd forward so that getPointer is the last bitstream operation. llvm-svn: 264409
* Bitcode: Use std::stable_partition for reproducible buildsDuncan P. N. Exon Smith2016-03-251-2/+2
| | | | | | | Caught by inspection while working on partitioning metadata. It's nice to produce the same bitcode if you run the compiler twice. llvm-svn: 264381
* BitcodeWriter: Move abbreviation for GenericDINode; almost NFCDuncan P. N. Exon Smith2016-03-241-2/+1
| | | | | | | | | | | | Simplify ValueEnumerator and WriteModuleMetadata by shifting the logic for the METADATA_GENERIC_DEBUG abbreviation into WriteGenericDINode. (This is just like r264302, but for GenericDINode.) The only change is that the abbreviation is emitted later in the bitcode, just before the first `GenericDINode` record. This shouldn't be observable though. llvm-svn: 264303
* BitcodeWriter: Move abbreviation for DILocation; almost NFCDuncan P. N. Exon Smith2016-03-241-2/+1
| | | | | | | | | | | Simplify ValueEnumerator and WriteModuleMetadata by shifting the logic for the METADATA_LOCATION abbreviation into WriteDILocation. The only change is that the abbreviation is emitted later in the bitcode, just before the first `DILocation` record. This shouldn't be observable though. llvm-svn: 264302
* Annotate dump() methods with LLVM_DUMP_METHOD, addressing Richard Smith ↵Yaron Keren2016-01-291-1/+1
| | | | | | | | r259192 post commit comment. clang part in r259232, this is the LLVM part of the patch. llvm-svn: 259240
* Rename MDValue* to Metadata* (NFC)Teresa Johnson2015-12-291-8/+8
| | | | | | | Renamed MDValue* to Metadata*, and MDValueToValIDMap to MetadataToIDs, as per review for r255909. llvm-svn: 256593
* Re-reapply "[IR] Move optional data in llvm::Function into a hungoff uselist"Vedant Kumar2015-12-191-28/+8
| | | | | | | | | | | | | | | | | Make personality functions, prefix data, and prologue data hungoff operands of Function. This is based on the email thread "[RFC] Clean up the way we store optional Function data" on llvm-dev. Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback! Includes a fix to scrub value subclass data in dropAllReferences. Does not use binary literals. Differential Revision: http://reviews.llvm.org/D13829 llvm-svn: 256095
* Revert "Reapply "[IR] Move optional data in llvm::Function into a hungoff ↵Vedant Kumar2015-12-191-8/+28
| | | | | | | | | | uselist"" This reverts commit r256093. This broke lld-x86_64-win7 because of -Werror,-Wc++1y-extensions. llvm-svn: 256094
* Reapply "[IR] Move optional data in llvm::Function into a hungoff uselist"Vedant Kumar2015-12-191-28/+8
| | | | | | | | | | | | | | | | Make personality functions, prefix data, and prologue data hungoff operands of Function. This is based on the email thread "[RFC] Clean up the way we store optional Function data" on llvm-dev. Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback! Includes a fix to scrub value subclass data in dropAllReferences. Differential Revision: http://reviews.llvm.org/D13829 llvm-svn: 256093
* Revert "[IR] Move optional data in llvm::Function into a hungoff uselist"Vedant Kumar2015-12-191-8/+28
| | | | | | | | This reverts commit r256090. This broke llvm-clang-lld-x86_64-debian-fast. llvm-svn: 256091
* [IR] Move optional data in llvm::Function into a hungoff uselistVedant Kumar2015-12-191-28/+8
| | | | | | | | | | | | | | Make personality functions, prefix data, and prologue data hungoff operands of Function. This is based on the email thread "[RFC] Clean up the way we store optional Function data" on llvm-dev. Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback! Differential Revision: http://reviews.llvm.org/D13829 llvm-svn: 256090
OpenPOWER on IntegriCloud