summaryrefslogtreecommitdiffstats
path: root/llvm/unittests
Commit message (Collapse)AuthorAgeFilesLines
...
* [Orc] Require target support for host before running execution unit tests.Lang Hames2015-10-281-3/+6
| | | | | | | Orc unit tests that execute code shouldn't run if the compiler doesn't have target support for the host machine. llvm-svn: 251551
* OrcJITTests: Prune unused libdeps.NAKAMURA Takumi2015-10-281-2/+0
| | | | llvm-svn: 251506
* OrcJITTests: Update libdeps.NAKAMURA Takumi2015-10-281-0/+1
| | | | llvm-svn: 251504
* Fix a -Wpessimizing-move warning.Craig Topper2015-10-281-1/+1
| | | | llvm-svn: 251495
* [Orc] Disable Orc C API unit tests on non-Darwin while I investigate moreLang Hames2015-10-281-1/+1
| | | | | | builder failures. llvm-svn: 251484
* [Orc] Re-add C bindings for the Orc APIs, with a fix to remove the union thatLang Hames2015-10-285-3/+150
| | | | | | | | | was causing builder failures. The bindings were originally added in r251472, and reverted in r251473 due to the builder failures. llvm-svn: 251482
* [Orc] Revert the C bindngs commit, r251472, while I debug some builder failures.Lang Hames2015-10-285-150/+3
| | | | llvm-svn: 251473
* [Orc] Add experimental C bindings for Orc.Lang Hames2015-10-285-3/+150
| | | | llvm-svn: 251472
* [Orc] Fix indentation.Lang Hames2015-10-271-35/+35
| | | | llvm-svn: 251423
* [X86] Make elfiamcu an OS, not an environment.Michael Kuperstein2015-10-271-3/+3
| | | | | | | | | | GNU tools require elfiamcu to take up the entire OS field, so, e.g. i?86-*-linux-elfiamcu is not considered a legal triple. Make us compatible. Differential Revision: http://reviews.llvm.org/D14081 llvm-svn: 251390
* [X86] Add support for elfiamcu tripleMichael Kuperstein2015-10-251-0/+6
| | | | | | | | This adds support for the i?86-*-elfiamcu triple, which indicates the IAMCU psABI is used. Differential Revision: http://reviews.llvm.org/D13977 llvm-svn: 251222
* Add a RAW mode to StringTableBuilder.Rafael Espindola2015-10-231-4/+4
| | | | | | | | | | | | In this mode it just tries to tail merge the strings without imposing any other format constrains. It will not, for example, add a null byte between them. Also add support for keeping a tentative size and offset if we decide to not optimize after all. This will be used shortly in lld for merging SHF_STRINGS sections. llvm-svn: 251153
* [IR] Add a `makeNoWrapRegion` method to `ConstantRange`Sanjoy Das2015-10-221-0/+52
| | | | | | | | | | | | Summary: This will be used in a future change to ScalarEvolution. Reviewers: hfinkel, reames, nlewycky Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13612 llvm-svn: 250975
* [Option] Use an ArrayRef to store the Option Infos in OptTable. NFCCraig Topper2015-10-211-1/+1
| | | | llvm-svn: 250901
* [AA] Enhance the new AliasAnalysis infrastructure with an optionalChandler Carruth2015-10-211-1/+166
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "external" AA wrapper pass. This is a generic hook that can be used to thread custom code into the primary AAResultsWrapperPass for the legacy pass manager in order to allow it to merge external AA results into the AA results it is building. It does this by threading in a raw callback and so it is *very* powerful and should serve almost any use case I have come up with for extending the set of alias analyses used. The only thing not well supported here is using a *different order* of alias analyses. That form of extension *is* supportable with the new pass manager, and I can make the callback structure here more elaborate to support it in the legacy pass manager if this is a critical use case that people are already depending on, but the only use cases I have heard of thus far should be reasonably satisfied by this simpler extension mechanism. It is hard to test this using normal facilities (the built-in AAs don't use this for obvious reasons) so I've written a fairly extensive set of custom passes in the alias analysis unit test that should be an excellent test case because it models the out-of-tree users: it adds a totally custom AA to the system. This should also serve as a reasonably good example and guide for out-of-tree users to follow in order to rig up their existing alias analyses. No support in opt for commandline control is provided here however. I'm really unhappy with the kind of contortions that would be required to support that. It would fully re-introduce the analysis group self-recursion kind of patterns. =/ I've heard from out-of-tree users that this will unblock their use cases with extending AAs on top of the new infrastructure and let us retain the new analysis-group-free-world. Differential Revision: http://reviews.llvm.org/D13418 llvm-svn: 250894
* unittests: Remove implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-10-2010-53/+52
| | | | llvm-svn: 250843
* [Orc] Make CompileOnDemandLayer::findSymbol call BaseLayer::findSymbol if noLang Hames2015-10-203-0/+165
| | | | | | symbol definition is found in the logical dylibs. llvm-svn: 250796
* Fix path::home_directory() unit test.Pawel Bylica2015-10-161-8/+12
| | | | | | It turns out that constructing std::string from null pointer is not the very best idea. llvm-svn: 250506
* SupportTests::HomeDirectory: Don't try tests when $HOME is undefined.NAKAMURA Takumi2015-10-161-6/+9
| | | | | | Lit sanitizes env vars. $HOME is not exported in Lit tests. llvm-svn: 250505
* Reformat.NAKAMURA Takumi2015-10-161-1/+1
| | | | llvm-svn: 250504
* Use Windows Vista API to get the user's home directoryPawel Bylica2015-10-161-9/+13
| | | | | | | | | | | | Summary: This patch replaces usage of deprecated SHGetFolderPathW with SHGetKnownFolderPath. The usage of SHGetKnownFolderPath is wrapped to allow queries for other "known" folders in the near future. Reviewers: aaron.ballman, gbedwell Subscribers: chapuni, llvm-commits Differential Revision: http://reviews.llvm.org/D13753 llvm-svn: 250501
* Initial migration of AVR backendDylan McKay2015-10-161-0/+17
| | | | | | | | This patch adds the underlying infrastructure for an AVR backend to be included into LLVM. It is the first of a series of patches aimed at moving the out-of-tree AVR backend into the tree. It consists of adding a new`Triple` target 'avr'. llvm-svn: 250492
* Recommit r250345, it was reverted in r250366 to investigate a bot failure.Manman Ren2015-10-151-0/+41
| | | | | | Our internal bot is still red after r250366. llvm-svn: 250415
* Remove DIFile from createSubroutineType.Eric Christopher2015-10-152-3/+3
| | | | | | Patch by Amaury Sechet with a small modification by me. llvm-svn: 250374
* Temporarily revert r250345 to sort out bot failure.Manman Ren2015-10-151-41/+0
| | | | | | | | | | | | | | With r250345 and r250343, we start to observe the following failure when bootstrap clang with lto and pgo: PHI node entries do not match predecessors! %.sroa.029.3.i = phi %"class.llvm::SDNode.13298"* [ null, %30953 ], [ null, %31017 ], [ null, %30998 ], [ null, %_ZN4llvm8dyn_castINS_14ConstantSDNodeENS_7SDValueEEENS_10cast_rettyIT_T0_E8ret_typeERS5_.exit.i.1804 ], [ null, %30975 ], [ null, %30991 ], [ null, %_ZNK4llvm3EVT13getScalarTypeEv.exit.i.1812 ], [ %..sroa.029.0.i, %_ZN4llvm11SmallVectorIiLj8EED1Ev.exit.i.1826 ], !dbg !451895 label %30998 label %_ZNK4llvm3EVTeqES0_.exit19.thread.i LLVM ERROR: Broken function found, compilation aborted! I will re-commit this if the bot does not recover. llvm-svn: 250366
* Update the branch weight metadata in JumpThreading pass.Cong Hou2015-10-141-0/+41
| | | | | | | | | | Currently in JumpThreading pass, the branch weight metadata is not updated after CFG modification. Consider the jump threading on PredBB, BB, and SuccBB. After jump threading, the weight on BB->SuccBB should be adjusted as some of it is contributed by the edge PredBB->BB, which doesn't exist anymore. This patch tries to update the edge weight in metadata on BB->SuccBB by scaling it by 1 - Freq(PredBB->BB) / Freq(BB->SuccBB). This is the third attempt to submit this patch, while the first two led to failures in some FDO tests. After investigation, it is the edge weight normalization that caused those failures. In this patch the edge weight normalization is fixed so that there is no zero weight in the output and the sum of all weights can fit in 32-bit integer. Several unit tests are added. Differential revision: http://reviews.llvm.org/D10979 llvm-svn: 250345
* Add - and -= operators to BlockFrequency using saturating arithmetic.Cong Hou2015-10-121-0/+6
| | | | llvm-svn: 250077
* Fix rename() sometimes failing if another process uses openFileForRead()Greg Bedwell2015-10-122-0/+114
| | | | | | | | | | | | | | | | | | | On Windows, fs::rename() could fail is another process was reading the file at the same time using fs::openFileForRead(). In most cases the user wouldn't notice as fs::rename() will continue to retry for 2000ms. Typically this is enough for the read to complete and a retry to succeed, but if the disk is being it too hard then the response time might be longer than the retry time and the rename would fail with a permission error. Add FILE_SHARE_DELETE to the sharing flags for CreateFileW() in fs::openFileForRead() and try ReplaceFileW() prior to MoveFileExW() in fs::rename(). Based on an initial patch by Edd Dawson! Differential Revision: http://reviews.llvm.org/D13647 llvm-svn: 250046
* Fix another UBSan test error from r248897 and follow on fix r249689Teresa Johnson2015-10-081-0/+84
| | | | | | | While here fix a few more issues with potential overflow and add new tests for these cases. Ensured that test now passes with UBSan. llvm-svn: 249745
* Fix Clang-tidy modernize-use-nullptr warnings in source directories and ↵Hans Wennborg2015-10-064-18/+15
| | | | | | | | | | generated files; other minor cleanups. Patch by Eugene Zelenko! Differential Revision: http://reviews.llvm.org/D13321 llvm-svn: 249482
* Make test resilient against windows path separators.Benjamin Kramer2015-10-051-0/+1
| | | | llvm-svn: 249320
* [Support] Add a version of fs::make_absolute with a custom CWD.Benjamin Kramer2015-10-051-0/+4
| | | | | | This will be used soon from clang. llvm-svn: 249309
* Add support for sub-byte aligned writes to lib/Support/Endian.hTeresa Johnson2015-09-301-0/+48
| | | | | | | | | | | | | | | Summary: As per Duncan's review for D12536, I extracted the sub-byte bit aligned reading and writing code into lib/Support, and generalized it. Added calls from BackpatchWord. Also added unittests. Reviewers: dexonsmith Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13189 llvm-svn: 248897
* InstrProf: Support for value profiling in the indexed profile formatJustin Bogner2015-09-292-10/+20
| | | | | | | | | Add support to the indexed instrprof reader and writer for the format that will be used for value profiling. Patch by Betul Buyukkurt, with minor modifications. llvm-svn: 248833
* HHVM calling conventions.Maksim Panchenko2015-09-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | HHVM calling convention, hhvmcc, is used by HHVM JIT for functions in translated cache. We currently support LLVM back end to generate code for X86-64 and may support other architectures in the future. In HHVM calling convention any GP register could be used to pass and return values, with the exception of R12 which is reserved for thread-local area and is callee-saved. Other than R12, we always pass RBX and RBP as args, which are our virtual machine's stack pointer and frame pointer respectively. When we enter translation cache via hhvmcc function, we expect the stack to be aligned at 16 bytes, i.e. skewed by 8 bytes as opposed to standard ABI alignment. This affects stack object alignment and stack adjustments for function calls. One extra calling convention, hhvm_ccc, is used to call C++ helpers from HHVM's translation cache. It is almost identical to standard C calling convention with an exception of first argument which is passed in RBP (before we use RDI, RSI, etc.) Differential Revision: http://reviews.llvm.org/D12681 llvm-svn: 248832
* Use fixed-point representation for BranchProbability.Cong Hou2015-09-252-85/+93
| | | | | | | | | | | | | | | | | | | | BranchProbability now is represented by its numerator and denominator in uint32_t type. This patch changes this representation into a fixed point that is represented by the numerator in uint32_t type and a constant denominator 1<<31. This is quite similar to the representation of BlockMass in BlockFrequencyInfoImpl.h. There are several pros and cons of this change: Pros: 1. It uses only a half space of the current one. 2. Some operations are much faster like plus, subtraction, comparison, and scaling by an integer. Cons: 1. Constructing a probability using arbitrary numerator and denominator needs additional calculations. 2. It is a little less precise than before as we use a fixed denominator. For example, 1 - 1/3 may not be exactly identical to 1 / 3 (this will lead to many BranchProbability unit test failures). This should not matter when we only use it for branch probability. If we use it like a rational value for some precise calculations we may need another construct like ValueRatio. One important reason for this change is that we propose to store branch probabilities instead of edge weights in MachineBasicBlock. We also want clients to use probability instead of weight when adding successors to a MBB. The current BranchProbability has more space which may be a concern. Differential revision: http://reviews.llvm.org/D12603 llvm-svn: 248633
* Add a unit test for r248341.Adrian Prantl2015-09-221-1/+1
| | | | llvm-svn: 248348
* Simplify SmallBitVector::applyMask by consolidating common code for 32- and ↵Yaron Keren2015-09-181-2/+2
| | | | | | | | | | | | | 64-bit builds and assert when mask is too large to apply in the small case, previously the extra words were silently ignored. clang-format the entire function to match current code standards. This is a rewrite of r247972 which was reverted in r247983 due to warning and possible UB on 32-bits hosts. llvm-svn: 247993
* Reverting r247972 (and subordinate commit r247972) as the 32-bit left-shift ↵Aaron Ballman2015-09-181-2/+2
| | | | | | is undefined behavior on implementations where uinptr_t is 32-bits. One such platform is Windows, MSVC, x86. llvm-svn: 247983
* Fix BitVectorTest on 32-bit hosts after r247972.Yaron Keren2015-09-181-2/+2
| | | | | | | We can't apply two words of 32-bit mask in the small case where the internal storage is just one 32-bit word. llvm-svn: 247974
* Simplify SmallBitVector::applyMask by consolidating common code for 32-bit ↵Yaron Keren2015-09-181-2/+2
| | | | | | | | | | | | | and 64-bit builds. Extend mask value to 64 bits before taking its complement and assert when mask is too large to apply in the small case (previously the extra words were silently ignored). http://reviews.llvm.org/D11890 Patch by James Touton! llvm-svn: 247972
* Revert "[opaque pointer type] Pass GlobalAlias the actual pointer type ↵David Blaikie2015-09-141-2/+2
| | | | | | | | | | | | | | | | | rather than decomposing it into pointee type + address space" This was a flawed change - it just caused the getElementType call to be deferred until later, when we really need to remove it. Now that the IR for GlobalAliases has been updated, the root cause is addressed that way instead and this change is no longer needed (and in fact gets in the way - because we want to pass the pointee type directly down further). Follow up patches to push this through GlobalValue, bitcode format, etc, will come along soon. This reverts commit 236160. llvm-svn: 247585
* Pass BranchProbability/BlockMass by value instead of const& as they are ↵Cong Hou2015-09-101-1/+1
| | | | | | small. NFC. llvm-svn: 247357
* [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
OpenPOWER on IntegriCloud