summaryrefslogtreecommitdiffstats
path: root/llvm/unittests
Commit message (Collapse)AuthorAgeFilesLines
* [ADT] Fix a confusing interface spec and some annoying peculiaritiesChandler Carruth2015-09-101-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | with the StringRef::split method when used with a MaxSplit argument other than '-1' (which nobody really does today, but which should actually work). The spec claimed both to split up to MaxSplit times, but also to append <= MaxSplit strings to the vector. One of these doesn't make sense. Given the name "MaxSplit", let's go with it being a max over how many *splits* occur, which means the max on how many strings get appended is MaxSplit+1. I'm not actually sure the implementation correctly provided this logic either, as it used a really opaque loop structure. The implementation was also playing weird games with nullptr in the data field to try to rely on a totally opaque hidden property of the split method that returns a pair. Nasty IMO. Replace all of this with what is (IMO) simpler code that doesn't use the pair returning split method, and instead just finds each separator and appends directly. I think this is a lot easier to read, and it most definitely matches the spec. Added some tests that exercise the corner cases around StringRef() and StringRef("") that all now pass. I'll start using this in code in the next commit. llvm-svn: 247249
* [ADT] Switch a bunch of places in LLVM that were doing single-characterChandler Carruth2015-09-101-4/+4
| | | | | | | splits to actually use the single character split routine which does less work, and in a debug build is *substantially* faster. llvm-svn: 247245
* [ADT] Add a single-character version of the small vector split routineChandler Carruth2015-09-101-0/+5
| | | | | | | | | | | on StringRef. Finding and splitting on a single character is substantially faster than doing it on even a single character StringRef -- we immediately get to a *very* tuned memchr call this way. Even nicer, we get to this even in a debug build, shaving 18% off the runtime of TripleTest.Normalization, helping PR23676 some more. llvm-svn: 247244
* Add makeArrayRef() overload for ArrayRef input (no-op/identity) NFCMehdi Amini2015-09-101-0/+16
| | | | | | | | | | | | | | | The purpose is to allow templated wrapper to work with either ArrayRef or any convertible operation: template<typename Container> void wrapper(const Container &Arr) { impl(makeArrayRef(Arr)); } with Container being a std::vector, a SmallVector, or an ArrayRef. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 247214
* [PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatibleChandler Carruth2015-09-093-50/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with the new pass manager, and no longer relying on analysis groups. This builds essentially a ground-up new AA infrastructure stack for LLVM. The core ideas are the same that are used throughout the new pass manager: type erased polymorphism and direct composition. The design is as follows: - FunctionAAResults is a type-erasing alias analysis results aggregation interface to walk a single query across a range of results from different alias analyses. Currently this is function-specific as we always assume that aliasing queries are *within* a function. - AAResultBase is a CRTP utility providing stub implementations of various parts of the alias analysis result concept, notably in several cases in terms of other more general parts of the interface. This can be used to implement only a narrow part of the interface rather than the entire interface. This isn't really ideal, this logic should be hoisted into FunctionAAResults as currently it will cause a significant amount of redundant work, but it faithfully models the behavior of the prior infrastructure. - All the alias analysis passes are ported to be wrapper passes for the legacy PM and new-style analysis passes for the new PM with a shared result object. In some cases (most notably CFL), this is an extremely naive approach that we should revisit when we can specialize for the new pass manager. - BasicAA has been restructured to reflect that it is much more fundamentally a function analysis because it uses dominator trees and loop info that need to be constructed for each function. All of the references to getting alias analysis results have been updated to use the new aggregation interface. All the preservation and other pass management code has been updated accordingly. The way the FunctionAAResultsWrapperPass works is to detect the available alias analyses when run, and add them to the results object. This means that we should be able to continue to respect when various passes are added to the pipeline, for example adding CFL or adding TBAA passes should just cause their results to be available and to get folded into this. The exception to this rule is BasicAA which really needs to be a function pass due to using dominator trees and loop info. As a consequence, the FunctionAAResultsWrapperPass directly depends on BasicAA and always includes it in the aggregation. This has significant implications for preserving analyses. Generally, most passes shouldn't bother preserving FunctionAAResultsWrapperPass because rebuilding the results just updates the set of known AA passes. The exception to this rule are LoopPass instances which need to preserve all the function analyses that the loop pass manager will end up needing. This means preserving both BasicAAWrapperPass and the aggregating FunctionAAResultsWrapperPass. Now, when preserving an alias analysis, you do so by directly preserving that analysis. This is only necessary for non-immutable-pass-provided alias analyses though, and there are only three of interest: BasicAA, GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is preserved when needed because it (like DominatorTree and LoopInfo) is marked as a CFG-only pass. I've expanded GlobalsAA into the preserved set everywhere we previously were preserving all of AliasAnalysis, and I've added SCEVAA in the intersection of that with where we preserve SCEV itself. One significant challenge to all of this is that the CGSCC passes were actually using the alias analysis implementations by taking advantage of a pretty amazing set of loop holes in the old pass manager's analysis management code which allowed analysis groups to slide through in many cases. Moving away from analysis groups makes this problem much more obvious. To fix it, I've leveraged the flexibility the design of the new PM components provides to just directly construct the relevant alias analyses for the relevant functions in the IPO passes that need them. This is a bit hacky, but should go away with the new pass manager, and is already in many ways cleaner than the prior state. Another significant challenge is that various facilities of the old alias analysis infrastructure just don't fit any more. The most significant of these is the alias analysis 'counter' pass. That pass relied on the ability to snoop on AA queries at different points in the analysis group chain. Instead, I'm planning to build printing functionality directly into the aggregation layer. I've not included that in this patch merely to keep it smaller. Note that all of this needs a nearly complete rewrite of the AA documentation. I'm planning to do that, but I'd like to make sure the new design settles, and to flesh out a bit more of what it looks like in the new pass manager first. Differential Revision: http://reviews.llvm.org/D12080 llvm-svn: 247167
* Fix PR 24633 - Handle undef values when parsing standalone constants.Alex Lorenz2015-09-091-0/+4
| | | | llvm-svn: 247145
* Adding full stops to commentsBen Craig2015-09-041-2/+2
| | | | | | Also, test commit llvm-svn: 246855
* Fix APInt value initialization to give a zero value as any sane integer typeRichard Smith2015-09-041-0/+7
| | | | | | | should, rather than giving a broken value that doesn't even zero/sign-extend properly. llvm-svn: 246836
* Move twice-repeated clang path operation into a new function.Douglas Katzman2015-09-021-0/+10
| | | | | | And make it more robust in the edge case of exactly "./" as input. llvm-svn: 246711
* [RemoveDuplicatePHINodes] Start over after removing a PHI.Benjamin Kramer2015-09-021-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes RemoveDuplicatePHINodes more effective and fixes an assertion failure. Triggering the assertions requires a DenseSet reallocation so this change only contains a constructive test. I'll explain the issue with a small example. In the following function there's a duplicate PHI, %4 and %5 are identical. When this is found the DenseSet in RemoveDuplicatePHINodes contains %2, %3 and %4. define void @F() { br label %1 ; <label>:1 ; preds = %1, %0 %2 = phi i32 [ 42, %0 ], [ %4, %1 ] %3 = phi i32 [ 42, %0 ], [ %5, %1 ] %4 = phi i32 [ 42, %0 ], [ 23, %1 ] %5 = phi i32 [ 42, %0 ], [ 23, %1 ] br label %1 } after RemoveDuplicatePHINodes runs the function looks like this. %3 has changed and is now identical to %2, but RemoveDuplicatePHINodes never saw this. define void @F() { br label %1 ; <label>:1 ; preds = %1, %0 %2 = phi i32 [ 42, %0 ], [ %4, %1 ] %3 = phi i32 [ 42, %0 ], [ %4, %1 ] %4 = phi i32 [ 42, %0 ], [ 23, %1 ] br label %1 } If the DenseSet does a reallocation now it will reinsert all keys and stumble over %3 now having a different hash value than it had when inserted into the map for the first time. This change clears the set whenever a PHI is deleted and starts the progress from the beginning, allowing %3 to be deleted and avoiding inconsistent DenseSet state. This potentially has a negative performance impact because it rescans all PHIs, but I don't think that this ever makes a difference in practice. llvm-svn: 246694
* [ValueTracking] Minor comment change in testJames Molloy2015-09-021-2/+1
| | | | | | This test was updated in r246678 - fix a copypasta in a comment noticed post-commit. llvm-svn: 246679
* [ValueTracking] Look through casts when both operands are casts.James Molloy2015-09-021-0/+42
| | | | | | | | | | | We only looked through casts when one operand was a constant. We can also look through casts when both operands are non-constant, but both are in fact the same cast type. For example: %1 = icmp ult i8 %a, %b %2 = zext i8 %a to i32 %3 = zext i8 %b to i32 %4 = select i1 %1, i32 %2, i32 %3 llvm-svn: 246678
* Teach the target parsing framework to directly compute the length of allChandler Carruth2015-08-301-43/+43
| | | | | | | | | | of its strings when expanding the string literals from the macros, and push all of the APIs to be StringRef instead of C-string APIs. This (remarkably) removes a very non-trivial number of strlen calls. It even deletes code and complexity from one of the primary users -- Clang. llvm-svn: 246374
* DI: Set DILexicalBlock columns >= 65536 to 0/unknownDuncan P. N. Exon Smith2015-08-281-0/+26
| | | | | | | | | This fixes PR24621 and matches what we do for `DILocation`. Although the limit seems somewhat artificial, there are places in the backend that also assume 16-bit columns, so we may as well just be consistent about the limits. llvm-svn: 246349
* DI: Add Function::getSubprogram()Duncan P. N. Exon Smith2015-08-281-0/+12
| | | | | | | | | | | | | | | | | | Add `Function::setSubprogram()` and `Function::getSubprogram()`, convenience methods to forward to `setMetadata()` and `getMetadata()`, respectively, and deal in `DISubprogram` instead of `MDNode`. Also add a verifier check to enforce that `!dbg` attachments are always subprograms. Originally (when I had the llvm-dev discussion back in April) I thought I'd store a pointer directly on `llvm::Function` for these attachments -- we frequently have debug info, and that's much cheaper than using map in the context if there are no other function-level attachments -- but for now I'm just using the generic infrastructure. Let's add the extra complexity only if this shows up in a profile. llvm-svn: 246339
* Add a global mapping layer for Orc. Adapted from a patch by Andy Somogyi.Lang Hames2015-08-272-0/+56
| | | | | | Thanks Andy! llvm-svn: 246226
* AsmParser: Save and restore the parsing state for types using SlotMapping.Alex Lorenz2015-08-211-0/+36
| | | | | | | | | | | | | | | | | | | | | This commit extends the 'SlotMapping' structure and includes mappings for named and numbered types in it. The LLParser is extended accordingly to fill out those mappings at the end of module parsing. This information is useful when we want to parse standalone constant values at a later stage using the 'parseConstantValue' method. The constant values can be constant expressions, which can contain references to types. In order to parse such constant values, we have to restore the internal named and numbered mappings for the types in LLParser, otherwise the parser will report a parsing error. Therefore, this commit also introduces a new method called 'restoreParsingState' to LLParser, which uses the slot mappings to restore some of its internal parsing state. This commit is required to serialize constant value pointers in the machine memory operands for the MIR format. Reviewers: Duncan P. N. Exon Smith llvm-svn: 245740
* Allow Optionals to be compared to NoneDavid Blaikie2015-08-191-0/+13
| | | | | | | | | | | This is something like nullopt in std::experimental::optional. Optional could already be constructed from None, so this seems like an obvious extension from there. I have a use in a future patch for Clang, though it may not go that way/end up used - so this seemed worth committing now regardless. llvm-svn: 245518
* [PM/AA] Remove the last relics of the separate IPA library from LLVM,Chandler Carruth2015-08-184-4/+2
| | | | | | | | | | | | | | | | | | | | | folding the code into the main Analysis library. There already wasn't much of a distinction between Analysis and IPA. A number of the passes in Analysis are actually IPA passes, and there doesn't seem to be any advantage to separating them. Moreover, it makes it hard to have interactions between analyses that are both local and interprocedural. In trying to make the Alias Analysis infrastructure work with the new pass manager, it becomes particularly awkward to navigate this split. I've tried to find all the places where we referenced this, but I may have missed some. I have also adjusted the C API to continue to be equivalently functional after this change. Differential Revision: http://reviews.llvm.org/D12075 llvm-svn: 245318
* Add unit test for isLayoutIdentical(empty, empty).Yaron Keren2015-08-181-0/+8
| | | | | | | | | It was previously asserting in Visual C++ debug mode on a null iterator passed to std::equal. Test by Hans Wennborg! llvm-svn: 245270
* [PM] Port ScalarEvolution to the new pass manager.Chandler Carruth2015-08-171-14/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change makes ScalarEvolution a stand-alone object and just produces one from a pass as needed. Making this work well requires making the object movable, using references instead of overwritten pointers in a number of places, and other refactorings. I've also wired it up to the new pass manager and added a RUN line to a test to exercise it under the new pass manager. This includes basic printing support much like with other analyses. But there is a big and somewhat scary change here. Prior to this patch ScalarEvolution was never *actually* invalidated!!! Re-running the pass just re-wired up the various other analyses and didn't remove any of the existing entries in the SCEV caches or clear out anything at all. This might seem OK as everything in SCEV that can uses ValueHandles to track updates to the values that serve as SCEV keys. However, this still means that as we ran SCEV over each function in the module, we kept accumulating more and more SCEVs into the cache. At the end, we would have a SCEV cache with every value that we ever needed a SCEV for in the entire module!!! Yowzers. The releaseMemory routine would dump all of this, but that isn't realy called during normal runs of the pipeline as far as I can see. To make matters worse, there *is* actually a key that we don't update with value handles -- there is a map keyed off of Loop*s. Because LoopInfo *does* release its memory from run to run, it is entirely possible to run SCEV over one function, then over another function, and then lookup a Loop* from the second function but find an entry inserted for the first function! Ouch. To make matters still worse, there are plenty of updates that *don't* trip a value handle. It seems incredibly unlikely that today GVN or another pass that invalidates SCEV can update values in *just* such a way that a subsequent run of SCEV will incorrectly find lookups in a cache, but it is theoretically possible and would be a nightmare to debug. With this refactoring, I've fixed all this by actually destroying and recreating the ScalarEvolution object from run to run. Technically, this could increase the amount of malloc traffic we see, but then again it is also technically correct. ;] I don't actually think we're suffering from tons of malloc traffic from SCEV because if we were, the fact that we never clear the memory would seem more likely to have come up as an actual problem before now. So, I've made the simple fix here. If in fact there are serious issues with too much allocation and deallocation, I can work on a clever fix that preserves the allocations (while clearing the data) between each run, but I'd prefer to do that kind of optimization with a test case / benchmark that shows why we need such cleverness (and that can test that we actually make it faster). It's possible that this will make some things faster by making the SCEV caches have higher locality (due to being significantly smaller) so until there is a clear benchmark, I think the simple change is best. Differential Revision: http://reviews.llvm.org/D12063 llvm-svn: 245193
* [PM/AA] Hoist the interface to TBAA into a dedicated header along withChandler Carruth2015-08-141-0/+1
| | | | | | its creation function. Update the relevant includes accordingly. llvm-svn: 245019
* There is only one saver of strings.Rafael Espindola2015-08-131-1/+1
| | | | llvm-svn: 244854
* Return ErrorOr from FileOutputBuffer::create. NFC.Rafael Espindola2015-08-131-9/+16
| | | | llvm-svn: 244848
* Simplify PackedVector by removing user-defined special members that aren't ↵David Blaikie2015-08-121-12/+0
| | | | | | | | | | | | any different than the defaults This causes the other special members (like move and copy construction, and move assignment) to come through for free. Some code in clang was depending on the (deprecated, in the original code) copy ctor. Now that there's no user-defined special members, they're all available without any deprecation concerns. llvm-svn: 244835
* Fix UB in MCJIT test cases that relied on union type punningDavid Blaikie2015-08-111-52/+30
| | | | | | | | Reviewers: lhames, aaron.ballman Differential Revision: http://reviews.llvm.org/D11779 llvm-svn: 244644
* Add SmallString test trying to exercise the realloc() code pathYaron Keren2015-08-111-0/+11
| | | | | | by allocating a small size (will go through malloc) and then large size. llvm-svn: 244637
* Add support for floating-point minnum and maxnumJames Molloy2015-08-112-0/+149
| | | | | | | | | | | | | | | | | The select pattern recognition in ValueTracking (as used by InstCombine and SelectionDAGBuilder) only knew about integer patterns. This teaches it about minimum and maximum operations. matchSelectPattern() has been extended to return a struct containing the existing Flavor and a new enum defining the pattern's behavior when given one NaN operand. C minnum() is defined to return the non-NaN operand in this case, but the idiomatic C "a < b ? a : b" would return the NaN operand. ARM and AArch64 at least have different instructions for these different cases. llvm-svn: 244580
* Thread premissions through sys::fs::create_director{y|ies}Frederic Riss2015-08-061-0/+24
| | | | llvm-svn: 244268
* Fix Visual C++ error C2248: Yaron Keren2015-08-061-2/+2
| | | | | | | | | | | | 'llvm::TrailingObjects<`anonymous-namespace'::Class1,short,llvm::NoTrailingTypeArg>::additionalSizeToAlloc' : cannot access protected member declared in class 'llvm::TrailingObjects<`anonymous-namespace'::Class1,short,llvm::NoTrailingTypeArg>' I'm not sure how this compiles with gcc. Aren't protecteded members accessible only with protected or public inheritance? llvm-svn: 244199
* [PM/AA] Hoist the interface for BasicAA into a header file.Chandler Carruth2015-08-061-0/+1
| | | | | | | | | | | | | This is the first mechanical step in preparation for making this and all the other alias analysis passes available to the new pass manager. I'm factoring out all the totally boring changes I can so I'm moving code around here with no other changes. I've even minimized the formatting churn. I'll reformat and freshen comments on the interface now that its located in the right place so that the substantive changes don't triger this. llvm-svn: 244197
* Add a TrailingObjects template class.James Y Knight2015-08-052-0/+148
| | | | | | | | | | This is intended to help support the idiom of a class that has some other objects (or multiple arrays of different types of objects) appended on the end, which is used quite heavily in clang. Differential Revision: http://reviews.llvm.org/D11272 llvm-svn: 244164
* [ArrayRefTest] Work around a GCC 4.8 internal compiler error.Benjamin Kramer2015-08-051-5/+2
| | | | llvm-svn: 244023
* unittests/ADT/ArrayRefTest.cpp: Suppress r243995 on g++-4.8 for now to ↵NAKAMURA Takumi2015-08-051-0/+4
| | | | | | | | | | | | | | | unbreak bots. For example of mingw-w64-g++-4.8.1, llvm/unittests/ADT/ArrayRefTest.cpp: In member function 'virtual void {anonymous}::ArrayRefTest_AllocatorCopy_Test::TestBody()': llvm/unittests/ADT/ArrayRefTest.cpp:56:40: internal compiler error: in count_type_elements, at expr.c:5523 } Array3Src[] = {{"hello"}, {"world"}}; ^ Please submit a full bug report, with preprocessed source if appropriate. llvm-svn: 244017
* [ArrayRef] Make copy use std::uninitialized_copy.Benjamin Kramer2015-08-041-1/+13
| | | | | | | std::copy does not work for non-trivially copyable classes when we're copying into uninitialized memory. llvm-svn: 243995
* -Wdeprecated-clean: Fix cases of violating the rule of 5 in ways that are ↵David Blaikie2015-08-031-6/+6
| | | | | | | | | | | | | | | | | | | | | | deprecated in C++11 Various value handles needed to be copy constructible and copy assignable (mostly for their use in DenseMap). But to avoid an API that might allow accidental slicing, make these members protected in the base class and make derived classes final (the special members become implicitly public there - but disallowing further derived classes that might be sliced to the intermediate type). Might be worth having a warning a bit like -Wnon-virtual-dtor that catches public move/copy assign/ctors in classes with virtual functions. (suppressable in the same way - by making them protected in the base, and making the derived classes final) Could be fancier and only diagnose them when they're actually called, potentially. Also allow a few default implementations where custom implementations (especially with non-standard return types) were implemented. llvm-svn: 243909
* Fix memory leak in unit test of Bitcode/BitReaderTest.cppDerek Schuff2015-08-031-1/+3
| | | | | | | | | | | | Fixes obvious memory leak in test TestForEofAfterReadFailureOnDataStreamer. Also removes constexpr use from same test. Patch by Karl Schimpf. Differential Revision: http://reviews.llvm.org/D11735 llvm-svn: 243904
* [MCJIT] Fix a cast warning in the unit-test introduced in r243589.Lang Hames2015-08-031-1/+7
| | | | | | Thanks to Aaron Ballman for spotting this. llvm-svn: 243891
* Fix testing for end of stream in bitstream reader.Derek Schuff2015-08-031-0/+35
| | | | | | | | | | | | | | | | | | This fixes a bug found while working on the bitcode reader. In particular, the method BitstreamReader::AtEndOfStream doesn't always behave correctly when processing a data streamer. The method fillCurWord doesn't properly set CurWord/BitsInCurWord if the data streamer was already at eof, but GetBytes had not yet set the ObjectSize field of the streaming memory object. This patch fixes this problem, and provides a test to show that this problem has been fixed. Patch by Karl Schimpf. Differential Revision: http://reviews.llvm.org/D11391 llvm-svn: 243890
* DI: Disallow uniquable DICompileUnitsDuncan P. N. Exon Smith2015-08-031-79/+22
| | | | | | | | | | | | | | | | | | Since r241097, `DIBuilder` has only created distinct `DICompileUnit`s. The backend is liable to start relying on that (if it hasn't already), so make uniquable `DICompileUnit`s illegal and automatically upgrade old bitcode. This is a nice cleanup, since we can remove an unnecessary `DenseSet` (and the associated uniquing info) from `LLVMContextImpl`. Almost all the testcases were updated with this script: git grep -e '= !DICompileUnit' -l -- test | grep -v test/Bitcode | xargs sed -i '' -e 's,= !DICompileUnit,= distinct !DICompileUnit,' I imagine something similar should work for out-of-tree testcases. llvm-svn: 243885
* Linker: Move distinct MDNodes instead of cloningDuncan P. N. Exon Smith2015-08-032-0/+105
| | | | | | | | | | | | | | | | | | | | | Instead of cloning distinct `MDNode`s when linking in a module, just move them over. The module linker destroys the source module, so the old node would otherwise just be leaked on the context. Create the new node in place. This also reduces the number of cloned uniqued nodes (since it's less likely their operands have changed). This mapping strategy is only correct when we're discarding the source, so the linker turns it on via a ValueMapper flag, `RF_MoveDistinctMDs`. There's nothing observable in terms of `llvm-link` output here: the linked module should be semantically identical. I'll be adding more 'distinct' nodes to the debug info metadata graph in order to break uniquing cycles, so the benefits of this will partly come in future commits. However, we should get some gains immediately, since we have a fair number of 'distinct' `DILocation`s being linked in. llvm-svn: 243883
* DI: Remove DW_TAG_arg_variable and DW_TAG_auto_variableDuncan P. N. Exon Smith2015-07-311-31/+27
| | | | | | | | | | | | | | | | | | | | | | | | Remove the fake `DW_TAG_auto_variable` and `DW_TAG_arg_variable` tags, using `DW_TAG_variable` in their place Stop exposing the `tag:` field at all in the assembly format for `DILocalVariable`. Most of the testcase updates were generated by the following sed script: find test/ -name "*.ll" -o -name "*.mir" | xargs grep -l 'DILocalVariable' | xargs sed -i '' \ -e 's/tag: DW_TAG_arg_variable, //' \ -e 's/tag: DW_TAG_auto_variable, //' There were only a handful of tests in `test/Assembly` that I needed to update by hand. (Note: a follow-up could change `DILocalVariable::DILocalVariable()` to set the tag to `DW_TAG_formal_parameter` instead of `DW_TAG_variable` (as appropriate), instead of having that logic magically in the backend in `DbgVariable`. I've added a FIXME to that effect.) llvm-svn: 243774
* DI: Rewrite the DIBuilder local variable APIDuncan P. N. Exon Smith2015-07-311-2/+2
| | | | | | | | | | | | Replace the general `createLocalVariable()` with two more specific functions: `createParameterVariable()` and `createAutoVariable()`, and rewrite the documentation. Besides cleaning up the API, this avoids exposing the fake DWARF tags `DW_TAG_arg_variable` and `DW_TAG_auto_variable` to frontends, and is preparation for removing them completely. llvm-svn: 243764
* MCJITTests/MCJITCAPITest.cpp: Try to appease i686-win32.NAKAMURA Takumi2015-07-301-0/+1
| | | | llvm-svn: 243639
* Add amdopencl environment to tripleMatt Arsenault2015-07-301-0/+2
| | | | | | | This is used by the AMD x86 OpenCL implementation to change some ABI details on Windows and Linux. llvm-svn: 243627
* [MCJIT] Fix a memory leak in a unit test that was introduced in r243589.Lang Hames2015-07-301-0/+1
| | | | llvm-svn: 243609
* [MCJIT] Fix PR20656 by teaching MCJIT to honor ExecutionEngine's global mapping.Lang Hames2015-07-291-0/+33
| | | | | | | This is important for users of the C API who can't supply custom symbol resolvers yet. llvm-svn: 243589
* Reapply "Add reverse(ContainerTy) range adapter."Pete Cooper2015-07-292-0/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r243567, which ultimately reapplies r243563. The fix here was to use std::enable_if for overload resolution. Thanks to David Blaikie for lots of help on this, and for the extra tests! Original commit message follows: For cases where we needed a foreach loop in reverse over a container, we had to do something like for (const GlobalValue *GV : make_range(TypeInfos.rbegin(), TypeInfos.rend())) { This provides a convenience method which shortens this to for (const GlobalValue *GV : reverse(TypeInfos)) { There are 2 versions of this, with a preference to the rbegin() version. The first uses rbegin() and rend() to construct an iterator_range. The second constructs an iterator_range from the begin() and end() methods wrapped in std::reverse_iterator's. Reviewed by David Blaikie. llvm-svn: 243581
* Revert "Add reverse(ContainerTy) range adapter."Pete Cooper2015-07-292-78/+0
| | | | | | | | | This reverts commit r243563. The GCC buildbots were extremely unhappy about this. Reverting while we discuss a better way of doing overload resolution. llvm-svn: 243567
* Add reverse(ContainerTy) range adapter.Pete Cooper2015-07-292-0/+78
| | | | | | | | | | | | | | | | | | | | | | | For cases where we needed a foreach loop in reverse over a container, we had to do something like for (const GlobalValue *GV : make_range(TypeInfos.rbegin(), TypeInfos.rend())) { This provides a convenience method which shortens this to for (const GlobalValue *GV : reverse(TypeInfos)) { There are 2 versions of this, with a preference to the rbegin() version. The first uses rbegin() and rend() to construct an iterator_range. The second constructs an iterator_range from the begin() and end() methods wrapped in std::reverse_iterator's. Reviewed by David Blaikie. llvm-svn: 243563
OpenPOWER on IntegriCloud