summaryrefslogtreecommitdiff
path: root/include
Commit message (Collapse)AuthorAge
* [PM] Add a new-PM-style CGSCC pass manager using the newly addedChandler Carruth2014-04-21
| | | | | | | | | | | | | | | | | | | | | | | LazyCallGraph analysis framework. Wire it up all the way through the opt driver and add some very basic testing that we can build pass pipelines including these components. Still a lot more to do in terms of testing that all of this works, but the basic pieces are here. There is a *lot* of boiler plate here. It's something I'm going to actively look at reducing, but I don't have any immediate ideas that don't end up making the code terribly complex in order to fold away the boilerplate. Until I figure out something to minimize the boilerplate, almost all of this is based on the code for the existing pass managers, copied and heavily adjusted to suit the needs of the CGSCC pass management layer. The actual CG management still has a bunch of FIXMEs in it. Notably, we don't do *any* updating of the CG as it is potentially invalidated. I wanted to get this in place to motivate the new analysis, and add update APIs to the analysis and the pass management layers in concert to make sure that the *right* APIs are present. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206745 91177308-0d34-0410-b5e6-96231b3b80d8
* [C++11] Replace OwningPtr with std::unique_ptr in places where it doesn't ↵Benjamin Kramer2014-04-21
| | | | | | | | break the API. No functionality change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206740 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r206732 which is causing llc to crash on most of the build bots.Chandler Carruth2014-04-21
| | | | | | | | Original commit message: Implement builtins for safe division: safe.sdiv.iN, safe.udiv.iN, safe.srem.iN, safe.urem.iN (iN = i8, i61, i32, or i64). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206735 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement builtins for safe division: safe.sdiv.iN, safe.udiv.iN, safe.srem.iN,Michael Zolotukhin2014-04-21
| | | | | | | | safe.urem.iN (iN = i8, i16, i32, or i64). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206732 91177308-0d34-0410-b5e6-96231b3b80d8
* Protect the ArgList dtorDavid Blaikie2014-04-20
| | | | | | | | | | | | | It could even be made non-virtual if it weren't for bad compiler warnings. This demonstrates that ArgList objects aren't destroyed polymorphically and possibly that they aren't even used polymorphically. If that's the case, it might be possible to refactor the two ArgList types more separately and simplify the Arg ownership model. *continues experimenting* git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206727 91177308-0d34-0410-b5e6-96231b3b80d8
* Add missing #include found by modules build.Richard Smith2014-04-20
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206726 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove comment that hasn't been true for 5 yearsDavid Blaikie2014-04-20
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206725 91177308-0d34-0410-b5e6-96231b3b80d8
* Use unique_ptr to handle ownership of synthesized args in DerivedArgListDavid Blaikie2014-04-20
| | | | | | | | This might be able to be simplified further by using Arg as a value type in a linked list (to maintain pointer validity), but here's something simple to start with. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206724 91177308-0d34-0410-b5e6-96231b3b80d8
* [Mips] Add more special values for the st_other field in the symbolSimon Atanasyan2014-04-20
| | | | | | table entry for MIPS. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206716 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "blockfreq: Rewrite BlockFrequencyInfoImpl"Duncan P. N. Exon Smith2014-04-19
| | | | | | This reverts commit r206704, as expected. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206707 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply "blockfreq: Rewrite BlockFrequencyInfoImpl"Duncan P. N. Exon Smith2014-04-19
| | | | | | | | | | | | | | | | | | | | | This reverts commit r206677, reapplying my BlockFrequencyInfo rewrite. I've done a careful audit, added some asserts, and fixed a couple of bugs (unfortunately, they were in unlikely code paths). There's a small chance that this will appease the failing bots [1][2]. (If so, great!) If not, I have a follow-up commit ready that will temporarily add -debug-only=block-freq to the two failing tests, allowing me to compare the code path between what the failing bots and what my machines (and the rest of the bots) are doing. Once I've triggered those builds, I'll revert both commits so the bots go green again. [1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816 [2]: http://llvm-amd64.freebsd.your.org/b/builders/clang-i386-freebsd/builds/18445 <rdar://problem/14292693> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206704 91177308-0d34-0410-b5e6-96231b3b80d8
* Patch by Vadim ChugunovYaron Keren2014-04-19
| | | | | | | | | | | | | Win64 stack unwinder gets confused when execution flow "falls through" after a call to 'noreturn' function. This fixes the "missing epilogue" problem by emitting a trap instruction for IR 'unreachable' on x86_x64-pc-windows. A secondary use for it would be for anyone wanting to make double-sure that 'noreturn' functions, indeed, do not return. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206684 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "blockfreq: Rewrite BlockFrequencyInfoImpl" (#2)Duncan P. N. Exon Smith2014-04-19
| | | | | | | | | | | This reverts commit r206666, as planned. Still stumped on why the bots are failing. Sanitizer bots haven't turned anything up. If anyone can help me debug either of the failures (referenced in r206666) I'll owe them a beer. (In the meantime, I'll be auditing my patch for undefined behaviour.) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206677 91177308-0d34-0410-b5e6-96231b3b80d8
* OnDiskHashTable: Audit types and use offset_type consistentlyJustin Bogner2014-04-19
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206675 91177308-0d34-0410-b5e6-96231b3b80d8
* ProfileData: Avoid UB when readingJustin Bogner2014-04-19
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206674 91177308-0d34-0410-b5e6-96231b3b80d8
* OnDiskHashTable: Fix a think-o with offset_typeJustin Bogner2014-04-18
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206672 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply "blockfreq: Rewrite BlockFrequencyInfoImpl" (#2)Duncan P. N. Exon Smith2014-04-18
| | | | | | | | | | | | | | | | | | | This reverts commit r206628, reapplying r206622 (and r206626). Two tests are failing only on buildbots [1][2]: i.e., I can't reproduce on Darwin, and Chandler can't reproduce on Linux. Asan and valgrind don't tell us anything, but we're hoping the msan bot will catch it. So, I'm applying this again to get more feedback from the bots. I'll leave it in long enough to trigger builds in at least the sanitizer buildbots (it was failing for reasons unrelated to my commit last time it was in), and hopefully a few others.... and then I expect to revert a third time. [1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816 [2]: http://llvm-amd64.freebsd.your.org/b/builders/clang-i386-freebsd/builds/18445 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206666 91177308-0d34-0410-b5e6-96231b3b80d8
* ProfileData: Don't forward declare ComputeHash and make it static inlineJustin Bogner2014-04-18
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206663 91177308-0d34-0410-b5e6-96231b3b80d8
* ProfileData: Add support for the indexed instrprof formatJustin Bogner2014-04-18
| | | | | | | | This adds support for an indexed instrumentation based profiling format, which is just a small header and an on disk hash table. This format will be used by clang's -fprofile-instr-use= for PGO. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206656 91177308-0d34-0410-b5e6-96231b3b80d8
* [DWARF parser] Turn DILineInfo into a struct.Alexey Samsonov2014-04-18
| | | | | | | | | | | Immutable DILineInfo doesn't bring any benefits and complicates code. Also, use std::string instead of SmallString<16> for file and function names - their length can vary significantly. No functionality change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206654 91177308-0d34-0410-b5e6-96231b3b80d8
* OnDiskHashTable: Expect the Info type to declare the offset typeJustin Bogner2014-04-18
| | | | | | | | This changes the on-disk hash to get the type to use for offsets from the Info type, so that clients can be more flexible with the size of table they support. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206643 91177308-0d34-0410-b5e6-96231b3b80d8
* OnDiskHashTable: Expect the Info type to declare the hash sizeJustin Bogner2014-04-18
| | | | | | | | This changes the on-disk hash to get the size of a hash value from the Info type, so that clients can be more flexible with the types of hash they use. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206642 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove a couple of redundant copies of SmallVector::operator==.Benjamin Kramer2014-04-18
| | | | | | No functionality change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206635 91177308-0d34-0410-b5e6-96231b3b80d8
* Add range access to MCAssembler's symbol collection.David Blaikie2014-04-18
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206631 91177308-0d34-0410-b5e6-96231b3b80d8
* Update comment in LLVMBitCodes.h to reflect the actual bitcode recordReid Kleckner2014-04-18
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206630 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix uint -> size_t conversion warning.Matt Arsenault2014-04-18
| | | | | | | | | | This warning is disabled for the LLVM build, but external users of the header can still run into this. Patch by Ke Bai git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206629 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "blockfreq: Rewrite BlockFrequencyInfoImpl" (#2)Duncan P. N. Exon Smith2014-04-18
| | | | | | | | | This reverts commit r206622 and the MSVC fixup in r206626. Apparently the remotely failing tests are still failing, despite my attempt to fix the nondeterminism in r206621. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206628 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply "blockfreq: Rewrite BlockFrequencyInfoImpl"Duncan P. N. Exon Smith2014-04-18
| | | | | | | | | | | | | | This reverts commit r206556, effectively reapplying commit r206548 and its fixups in r206549 and r206550. In an intervening commit I've added target triples to the tests that were failing remotely [1] (but passing locally). I'm hoping the mystery is solved? I'll revert this again if the tests are still failing remotely. [1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206622 91177308-0d34-0410-b5e6-96231b3b80d8
* LineIterator: Add DataTypes.h for int64_t on MSVC.Benjamin Kramer2014-04-18
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206617 91177308-0d34-0410-b5e6-96231b3b80d8
* Add some missing includes for various standard library implementations.Benjamin Kramer2014-04-18
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206616 91177308-0d34-0410-b5e6-96231b3b80d8
* Make the copy member of StringRef/ArrayRef generic wrt allocators.Benjamin Kramer2014-04-18
| | | | | | | | Doesn't make sense to restrict this to BumpPtrAllocator. While there replace an explicit loop with std::equal. Some standard libraries know how to compile this down to a ::memcmp call if possible. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206615 91177308-0d34-0410-b5e6-96231b3b80d8
* Allocator: Remove ReferenceAdder hack.Benjamin Kramer2014-04-18
| | | | | | | This was a workaround for compilers that had issues with reference collapsing. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206612 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Remove all of the complexity stemming from supporting copying.Chandler Carruth2014-04-18
| | | | | | | | | | | | | | Reality is that we're never going to copy one of these. Supporting this was becoming a nightmare because nothing even causes it to compile most of the time. Lots of subtle errors built up that wouldn't have been caught by any "normal" testing. Also, make the move assignment actually work rather than the bogus swap implementation that would just infloop if used. As part of that, factor out the graph pointer updates into a helper to share between move construction and move assignment. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206583 91177308-0d34-0410-b5e6-96231b3b80d8
* [Allocator] Fix an obvious think-o with the move assignmentChandler Carruth2014-04-18
| | | | | | | implementation of the SpecificBumpPtrAllocator -- we have to actually move the subobject. =] Noticed when using this code more directly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206582 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Add support for building persistent and connected SCCs to theChandler Carruth2014-04-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LazyCallGraph. This is the start of the whole point of this different abstraction, but it is just the initial bits. Here is a run-down of what's going on here. I'm planning to incorporate some (or all) of this into comments going forward, hopefully with better editing and wording. =] The crux of the problem with the traditional way of building SCCs is that they are ephemeral. The new pass manager however really needs the ability to associate analysis passes and results of analysis passes with SCCs in order to expose these analysis passes to the SCC passes. Making this work is kind-of the whole point of the new pass manager. =] So, when we're building SCCs for the call graph, we actually want to build persistent nodes that stick around and can be reasoned about later. We'd also like the ability to walk the SCC graph in more complex ways than just the traditional postorder traversal of the current CGSCC walk. That means that in addition to being persistent, the SCCs need to be connected into a useful graph structure. However, we still want the SCCs to be formed lazily where possible. These constraints are quite hard to satisfy with the SCC iterator. Also, using that would bypass our ability to actually add data to the nodes of the call graph to facilite implementing the Tarjan walk. So I've re-implemented things in a more direct and embedded way. This immediately makes it easy to get the persistence and connectivity correct, and it also allows leveraging the existing nodes to simplify the algorithm. I've worked somewhat to make this implementation more closely follow the traditional paper's nomenclature and strategy, although it is still a bit obtuse because it isn't recursive, using an explicit stack and a tail call instead, and it is interruptable, resuming each time we need another SCC. The other tricky bit here, and what actually took almost all the time and trials and errors I spent building this, is exactly *what* graph structure to build for the SCCs. The naive thing to build is the call graph in its newly acyclic form. I wrote about 4 versions of this which did precisely this. Inevitably, when I experimented with them across various use cases, they became incredibly awkward. It was all implementable, but it felt like a complete wrong fit. Square peg, round hole. There were two overriding aspects that pushed me in a different direction: 1) We want to discover the SCC graph in a postorder fashion. That means the root node will be the *last* node we find. Using the call-SCC DAG as the graph structure of the SCCs results in an orphaned graph until we discover a root. 2) We will eventually want to walk the SCC graph in parallel, exploring distinct sub-graphs independently, and synchronizing at merge points. This again is not helped by the call-SCC DAG structure. The structure which, quite surprisingly, ended up being completely natural to use is the *inverse* of the call-SCC DAG. We add the leaf SCCs to the graph as "roots", and have edges to the caller SCCs. Once I switched to building this structure, everything just fell into place elegantly. Aside from general cleanups (there are FIXMEs and too few comments overall) that are still needed, the other missing piece of this is support for iterating across levels of the SCC graph. These will become useful for implementing #2, but they aren't an immediate priority. Once SCCs are in good shape, I'll be working on adding mutation support for incremental updates and adding the pass manager that this analysis enables. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206581 91177308-0d34-0410-b5e6-96231b3b80d8
* [ExecutionEngine] Allow JIT clients to enable/disable module verification.Lang Hames2014-04-18
| | | | | | | | | | | | | | Previously module verification was always enabled, with no way to turn it off. As of this commit, module verification is on by default in Debug builds, and off by default in release builds. The default behaviour can be overridden by calling setVerifyModules(bool) on the JIT instance (this works for both the old JIT, and MCJIT). <rdar://problem/16150008> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206561 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "blockfreq: Rewrite BlockFrequencyInfoImpl"Duncan P. N. Exon Smith2014-04-18
| | | | | | | | | | | This reverts commits r206548, r206549 and r206549. There are some unit tests failing that aren't failing locally [1], so reverting until I have time to investigate. [1]: http://bb.pgr.jp/builders/ninja-x64-msvc-RA-centos6/builds/1816 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206556 91177308-0d34-0410-b5e6-96231b3b80d8
* OnDiskHashTable: Provide iterator_range for keys and dataJustin Bogner2014-04-18
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206555 91177308-0d34-0410-b5e6-96231b3b80d8
* blockfreq: Rewrite BlockFrequencyInfoImplDuncan P. N. Exon Smith2014-04-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rewrite the shared implementation of BlockFrequencyInfo and MachineBlockFrequencyInfo entirely. The old implementation had a fundamental flaw: precision losses from nested loops (or very wide branches) compounded past loop exits (and convergence points). The @nested_loops testcase at the end of test/Analysis/BlockFrequencyAnalysis/basic.ll is motivating. This function has three nested loops, with branch weights in the loop headers of 1:4000 (exit:continue). The old analysis gives non-sensical results: Printing analysis 'Block Frequency Analysis' for function 'nested_loops': ---- Block Freqs ---- entry = 1.0 for.cond1.preheader = 1.00103 for.cond4.preheader = 5.5222 for.body6 = 18095.19995 for.inc8 = 4.52264 for.inc11 = 0.00109 for.end13 = 0.0 The new analysis gives correct results: Printing analysis 'Block Frequency Analysis' for function 'nested_loops': block-frequency-info: nested_loops - entry: float = 1.0, int = 8 - for.cond1.preheader: float = 4001.0, int = 32007 - for.cond4.preheader: float = 16008001.0, int = 128064007 - for.body6: float = 64048012001.0, int = 512384096007 - for.inc8: float = 16008001.0, int = 128064007 - for.inc11: float = 4001.0, int = 32007 - for.end13: float = 1.0, int = 8 Most importantly, the frequency leaving each loop matches the frequency entering it. The new algorithm leverages BlockMass and PositiveFloat to maintain precision, separates "probability mass distribution" from "loop scaling", and uses dithering to eliminate probability mass loss. I have unit tests for these types out of tree, but it was decided in the review to make the classes private to BlockFrequencyInfoImpl, and try to shrink them (or remove them entirely) in follow-up commits. The new algorithm should generally have a complexity advantage over the old. The previous algorithm was quadratic in the worst case. The new algorithm is still worst-case quadratic in the presence of irreducible control flow, but it's linear without it. The key difference between the old algorithm and the new is that control flow within a loop is evaluated separately from control flow outside, limiting propagation of precision problems and allowing loop scale to be calculated independently of mass distribution. Loops are visited bottom-up, their loop scales are calculated, and they are replaced by pseudo-nodes. Mass is then distributed through the function, which is now a DAG. Finally, loops are revisited top-down to multiply through the loop scales and the masses distributed to pseudo nodes. There are some remaining flaws. - Irreducible control flow isn't modelled correctly. LoopInfo and MachineLoopInfo ignore irreducible edges, so this algorithm will fail to scale accordingly. There's a note in the class documentation about how to get closer. See also the comments in test/Analysis/BlockFrequencyInfo/irreducible.ll. - Loop scale is limited to 4096 per loop (2^12) to avoid exhausting the 64-bit integer precision used downstream. - The "bias" calculation proposed on llvmdev is *not* incorporated here. This will be added in a follow-up commit, once comments from this review have been handled. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206548 91177308-0d34-0410-b5e6-96231b3b80d8
* PMBuilder: Expose an option to disable tail callsDuncan P. N. Exon Smith2014-04-18
| | | | | | | | Adds API to allow frontends to disable tail calls in PassManagerBuilder. <rdar://problem/16050591> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206542 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix bug 19437 - Only add discriminators for DWARF 4 and above.Diego Novillo2014-04-17
| | | | | | | | | | | | | | Summary: This prevents the discriminator generation pass from triggering if the DWARF version being used in the module is prior to 4. Reviewers: echristo, dblaikie CC: llvm-commits Differential Revision: http://reviews.llvm.org/D3413 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206507 91177308-0d34-0410-b5e6-96231b3b80d8
* ARM64: add acquire/release versions of the existing atomic intrinsics.Tim Northover2014-04-17
| | | | | | | These will be needed to support IR-level lowering of atomic operations. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206489 91177308-0d34-0410-b5e6-96231b3b80d8
* Atomics: promote ARM's IR-based atomics pass to CodeGen.Tim Northover2014-04-17
| | | | | | | | | | | | Still only 32-bit ARM using it at this stage, but the promotion allows direct testing via opt and is a reasonably self-contained patch on the way to switching ARM64. At this point, other targets should be able to make use of it without too much difficulty if they want. (See ARM64 commit coming soon for an example). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206485 91177308-0d34-0410-b5e6-96231b3b80d8
* Inliner::OptimizationRemark: Fix crash in ↵NAKAMURA Takumi2014-04-17
| | | | | | | | clang/test/Frontend/optimization-remark.c on some hosts, including --vg. DebugLoc in Callsite would not live after Inliner. It should be copied before Inliner. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206459 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Remove a dead declaration. This stopped being used when I switchedChandler Carruth2014-04-17
| | | | | | | to a more normal move operation on the graph itself. The definition already got removed, but I missed the declaration. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206455 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Move the call graph node class into the graph class's definition.Chandler Carruth2014-04-17
| | | | | | | This will become necessary to build up the SCC iterators and SCC definitions. Moving it now so that subsequent diffs are incremental. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206454 91177308-0d34-0410-b5e6-96231b3b80d8
* Make the User::value_op_iterator a random access iterator. I had writtenChandler Carruth2014-04-17
| | | | | | | | | this code ages ago and lost track of it. Seems worth doing though -- this thing can get called from places that would benefit from knowing that std::distance is O(1). Also add a very fledgeling unittest for Users and make sure various aspects of this seem to work reasonably. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206453 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Just move the allocator (now that we can) when moving a callChandler Carruth2014-04-17
| | | | | | | | | graph. This simplifies the custom move constructor operation to one of walking the graph and updating the 'up' pointers to point to the new location of the graph. Switch the nodes from a reference to a pointer for the 'up' edge to facilitate this. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206450 91177308-0d34-0410-b5e6-96231b3b80d8
* [LCG] Remove the Module reference member which we weren't using forChandler Carruth2014-04-17
| | | | | | anything and doesn't make sense if assigning. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206449 91177308-0d34-0410-b5e6-96231b3b80d8
* [Allocator] Make SpecificBumpPtrAllocator also movable and moveChandler Carruth2014-04-17
| | | | | | assignable. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206448 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-28 23:39:13 +0000