summaryrefslogtreecommitdiffstats
path: root/llvm/unittests
Commit message (Collapse)AuthorAgeFilesLines
* [BPI] Add multiplication by scalar operators to BranchProbabilitySerguei Katkov2017-04-211-0/+48
| | | | | | | | | | | | | | | This patch just adds two operators to BranchProbability class: (BP * scalar) and (BP *= scalar). Reviewers: junbuml, chandlerc, sanjoy, vsk Reviewed By: chandlerc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32334 llvm-svn: 300945
* [AsmWriter/APFloat] FP constant printing: Avoid usage of locale dependent ↵Serguei Katkov2017-04-211-2/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | snprinf This should fix the bug https://bugs.llvm.org/show_bug.cgi?id=12906 To print the FP constant AsmWriter does the following: 1) convert FP value to String (actually using snprintf function which is locale dependent). 2) Convert String back to FP Value 3) Compare original and got FP values. If they are not equal just dump as hex. The problem happens on the 2nd step when APFloat does not expect group delimiter or fraction delimiter other than period symbol and so on, which can be produced on the first step if LLVM library is used in an environment with corresponding locale set. To fix this issue the locale independent APFloat:toString function is used. However it prints FP values slightly differently than snprintf does. Specifically it suppress trailing zeros in significant, use capital E and so on. It results in 117 test failures during make check. To avoid this I've also updated APFloat.toString a bit to pass make check at least. Reviewers: sberg, bogner, majnemer, sanjoy, timshen, rnk Reviewed By: timshen, rnk Subscribers: rnk, llvm-commits Differential Revision: https://reviews.llvm.org/D32276 llvm-svn: 300943
* [DWARF] Versioning for DWARF constants; verify FORMsPaul Robinson2017-04-201-8/+14
| | | | | | | | | | | | | Associate the version-when-defined with definitions of standard DWARF constants. Identify the "vendor" for DWARF extensions. Use this information to verify FORMs in .debug_abbrev are defined as of the DWARF version specified in the associated unit. Removed two tests that had specified DWARF v1 (which essentially does not exist). Differential Revision: http://reviews.llvm.org/D30785 llvm-svn: 300875
* Resubmit "[BitVector] Add operator<<= and operator>>=."Zachary Turner2017-04-201-0/+122
| | | | | | | | | This was failing due to the use of assigning a Mask to an unsigned, rather than to a BitWord. But most systems do not have sizeof(unsigned) == sizeof(unsigned long), so the mask was getting truncated. llvm-svn: 300857
* [SVE] Fix mismatched sign comparison warning in unit test from r300842.Amara Emerson2017-04-201-2/+2
| | | | llvm-svn: 300855
* Revert "[BitVector] Add operator<<= and operator>>=."Zachary Turner2017-04-201-122/+0
| | | | | | | This is causing test failures on Linux / BSD systems. Reverting while I investigate. llvm-svn: 300852
* [APInt] Add isSubsetOf method that can check if one APInt is a subset of ↵Craig Topper2017-04-201-0/+29
| | | | | | | | | | | | | | another without creating temporary APInts This question comes up in many places in SimplifyDemandedBits. This makes it easy to ask without allocating additional temporary APInts. The BitVector class provides a similar functionality through its (IMHO badly named) test(const BitVector&) method. Though its output polarity is reversed. I've provided one example use case in this patch. I plan to do more as a follow up. Differential Revision: https://reviews.llvm.org/D32258 llvm-svn: 300851
* [BitVector] Add operator<<= and operator>>=.Zachary Turner2017-04-201-0/+122
| | | | | | Differential Revision: https://reviews.llvm.org/D32244 llvm-svn: 300848
* [MVT][SVE] Scalable vector MVTs (3/3)Amara Emerson2017-04-202-0/+89
| | | | | | | | | | | | Adds MVT::ElementCount to represent the length of a vector which may be scalable, then adds helper functions that work with it. Patch by Graham Hunter. Differential Revision: https://reviews.llvm.org/D32019 llvm-svn: 300842
* [ARM] Rename HW div feature to HW div Thumb. NFCI.Diana Picus2017-04-201-45/+52
| | | | | | | | | | | | | | | | The hardware div feature refers only to Thumb, but because of its name it is tempting to use it to check for hardware division in general, which may cause problems in ARM mode. See https://reviews.llvm.org/D32005. This patch adds "Thumb" to its name, to make its scope clear. One notable place where I haven't made the change is in the feature flag (used with -mattr), which is still hwdiv. Changing it would also require changes in a lot of tests, including clang tests, and it doesn't seem like it's worth the effort. Differential Revision: https://reviews.llvm.org/D32160 llvm-svn: 300827
* Recommit "[APInt] Add back the asserts that check that the APInt shift ↵Craig Topper2017-04-201-2/+2
| | | | | | | | methods aren't called with values larger than BitWidth." This includes a fix to clamp a right shift of larger than BitWidth in DAG combining. llvm-svn: 300816
* Revert r300811 "[APInt] Add back the asserts that check that the APInt shift ↵Craig Topper2017-04-201-2/+2
| | | | | | | | methods aren't called with values larger than BitWidth." This is failing a self host debug build. llvm-svn: 300813
* [APInt] Add back the asserts that check that the APInt shift methods aren't ↵Craig Topper2017-04-201-2/+2
| | | | | | | | called with values larger than BitWidth. The underlying tcShiftRight/tcShiftLeft functions support the larger bit widths but the APInt interface shouldn't rely on that. llvm-svn: 300811
* [APInt] Cast more calls to add/sub/mul overflow functions to void. I missed ↵Craig Topper2017-04-191-4/+4
| | | | | | the unittests in r300758. llvm-svn: 300773
* [MathExtras] Fix undefined behavior (shift by bit width)Benjamin Kramer2017-04-191-0/+5
| | | | | | While there add some unit tests for uint64_t. Found by ubsan. llvm-svn: 300721
* Prefer addAttr(Attribute::AttrKind) over the AttributeList overloadReid Kleckner2017-04-191-3/+1
| | | | | | | | This should simplify the call sites, which typically want to tweak one attribute at a time. It should also avoid creating ephemeral AttributeLists that live forever. llvm-svn: 300718
* [Support] Add some helpers to generate bitmasks.Zachary Turner2017-04-191-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | Frequently you you want a bitmask consisting of a specified number of 1s, either at the beginning or end of a word. The naive way to do this is to write template<typename T> T leadingBitMask(unsigned N) { return (T(1) << N) - 1; } but using this function you cannot produce a word with every bit set to 1 (i.e. leadingBitMask<uint8_t>(8)) because left shift is undefined when N is greater than or equal to the number of bits in the word. This patch provides an efficient, branch-free implementation that works for all values of N in [0, CHAR_BIT*sizeof(T)] Differential Revision: https://reviews.llvm.org/D32212 llvm-svn: 300710
* [GlobalISel] Support vector-of-pointers in LLTKristof Beyls2017-04-191-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes PR32471. As comment 10 on that bug report highlights (https://bugs.llvm.org//show_bug.cgi?id=32471#c10), there are quite a few different defendable design tradeoffs that could be made, including not representing pointers at all in LLT. I decided to go for representing vector-of-pointer as a concept in LLT, while keeping the size of the LLT type 64 bits (this is an increase from 48 bits before). My rationale for keeping pointers explicit is that on some targets probably it's very handy to have the distinction between pointer and non-pointer (e.g. 68K has a different register bank for pointers IIRC). If we keep a scalar pointer, it probably is easiest to also have a vector-of-pointers to keep LLT relatively conceptually clean and orthogonal, while we don't have a very strong reason to break that orthogonality. Once we gain more experience on the use of LLT, we can of course reconsider this direction. Rejecting vector-of-pointer types in the IRTranslator is also an option to avoid the crash reported in PR32471, but that is only a very short-term solution; also needs quite a bit of code tweaks in places, and is probably fragile. Therefore I didn't consider this the best option. llvm-svn: 300664
* Remove buggy 'addAttributes(unsigned, AttrBuilder)' overloadReid Kleckner2017-04-191-0/+5
| | | | | | | | | | The 'addAttributes(unsigned, AttrBuilder)' overload delegated to 'get' instead of 'addAttributes'. Since we can implicitly construct an AttrBuilder from an AttributeSet, just standardize on AttrBuilder. llvm-svn: 300651
* Fix crash in AttributeList::addAttributes, add testReid Kleckner2017-04-181-0/+9
| | | | llvm-svn: 300614
* Revert "[GlobalISel] Support vector-of-pointers in LLT"Kristof Beyls2017-04-181-11/+0
| | | | | | | | | | | | | | | | This reverts r300535 and r300537. The newly added tests in test/CodeGen/AArch64/GlobalISel/arm64-fallback.ll produces slightly different code between LLVM versions being built with different compilers. E.g., dependent on the compiler LLVM is built with, either one of the following can be produced: remark: <unknown>:0:0: unable to legalize instruction: %vreg0<def>(p0) = G_EXTRACT_VECTOR_ELT %vreg1, %vreg2; (in function: vector_of_pointers_extractelement) remark: <unknown>:0:0: unable to legalize instruction: %vreg2<def>(p0) = G_EXTRACT_VECTOR_ELT %vreg1, %vreg0; (in function: vector_of_pointers_extractelement) Non-determinism like this is clearly a bad thing, so reverting this until I can find and fix the root cause of the non-determinism. llvm-svn: 300538
* [GlobalISel] Support vector-of-pointers in LLTKristof Beyls2017-04-181-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes PR32471. As comment 10 on that bug report highlights (https://bugs.llvm.org//show_bug.cgi?id=32471#c10), there are quite a few different defendable design tradeoffs that could be made, including not representing pointers at all in LLT. I decided to go for representing vector-of-pointer as a concept in LLT, while keeping the size of the LLT type 64 bits (this is an increase from 48 bits before). My rationale for keeping pointers explicit is that on some targets probably it's very handy to have the distinction between pointer and non-pointer (e.g. 68K has a different register bank for pointers IIRC). If we keep a scalar pointer, it probably is easiest to also have a vector-of-pointers to keep LLT relatively conceptually clean and orthogonal, while we don't have a very strong reason to break that orthogonality. Once we gain more experience on the use of LLT, we can of course reconsider this direction. Rejecting vector-of-pointer types in the IRTranslator is also an option to avoid the crash reported in PR32471, but that is only a very short-term solution; also needs quite a bit of code tweaks in places, and is probably fragile. Therefore I didn't consider this the best option. llvm-svn: 300535
* [APInt] Make operator<<= shift in place. Improve the implementation of ↵Craig Topper2017-04-181-0/+33
| | | | | | tcShiftLeft and use it to implement operator<<=. llvm-svn: 300526
* [APInt] Merge the multiword code from lshrInPlace and tcShiftRight into a ↵Craig Topper2017-04-171-5/+33
| | | | | | | | | | | | single implementation This merges the two different multiword shift right implementations into a single version located in tcShiftRight. lshrInPlace now calls tcShiftRight for the multiword case. I retained the memmove fast path from lshrInPlace and used a memset for the zeroing. The for loop is basically tcShiftRight's implementation with the zeroing and the intra-shift of 0 removed. Differential Revision: https://reviews.llvm.org/D32114 llvm-svn: 300503
* [SCEV] Add a local cache for getZeroExtendExpr and getSignExtendExpr to preventWei Mi2017-04-171-0/+90
| | | | | | | | | | | | | | | | | | the exponential behavior. The patch is to fix PR32043. Functions getZeroExtendExpr and getSignExtendExpr may call themselves recursively more than once. This is potentially a 2^N complexity behavior. The exponential behavior was not commonly exposed before because of existing global cache mechnism like UniqueSCEVs or some early return mechanism when flags FlagNSW or FlagNUW are seen. However, we still have case which can expose the exponential behavior, like the case in PR32043, so we add a local cache in getZeroExtendExpr and getSignExtendExpr. If the input of the functions -- SCEV and type pair have been seen before, we can find the extended expression directly in the local cache. Differential Revision: https://reviews.llvm.org/D30350 llvm-svn: 300494
* [APInt] Remove self move check from move assignment operatorCraig Topper2017-04-171-30/+2
| | | | | | | | | | | | This was added to work around a bug in MSVC 2013's implementation of stable_sort. That bug has been fixed as of MSVC 2015 so we shouldn't need this anymore. Technically the current implementation has undefined behavior because we only protect the deleting of the pVal array with the self move check. There is still a memcpy of that.VAL to VAL that isn't protected. In the case of self move those are the same local and memcpy is undefined for src and dst overlapping. This reduces the size of the opt binary on my local x86-64 build by about 4k. Differential Revision: https://reviews.llvm.org/D32116 llvm-svn: 300477
* [APInt] Fix a bug in lshr by a value more than 64 bits above the bit width.Craig Topper2017-04-161-0/+5
| | | | | | This was throwing an assert because we determined the intra-word shift amount by subtracting the size of the full word shift from the total shift amount. But we failed to account for the fact that we clipped the full word shifts by total words first. To fix this just calculate the intra-word shift as the remainder of dividing by bits per word. llvm-svn: 300405
* Generalize SCEV's unit testing helper a bitSanjoy Das2017-04-141-10/+11
| | | | llvm-svn: 300379
* [IR] Make paramHasAttr to use arg indices instead of attr indicesReid Kleckner2017-04-141-1/+1
| | | | | | | | | This avoids the confusing 'CS.paramHasAttr(ArgNo + 1, Foo)' pattern. Previously we were testing return value attributes with index 0, so I introduced hasReturnAttr() for that use case. llvm-svn: 300367
* [ValueTracking] Avoid undefined behavior in unittest by not making a named ↵Craig Topper2017-04-141-1/+1
| | | | | | | | | | | | ArrayRef from a std::initializer_list One of the ValueTracking unittests creates a named ArrayRef initialized by a std::initializer_list. The underlying array for an std::initializer_list is only guaranteed to have a lifetime as long as the initializer_list object itself. So this can leave the ArrayRef pointing at an array that no long exists. This fixes this to just create an explicit array instead of an ArrayRef. Differential Revision: https://reviews.llvm.org/D32089 llvm-svn: 300354
* Add a unit test for SCEV NormalizationSanjoy Das2017-04-141-0/+63
| | | | llvm-svn: 300332
* Add more test cases for StringRef::edit_distanceAlex Denisov2017-04-141-2/+16
| | | | | | Example strings taken from here: http://www.let.rug.nl/~kleiweg/lev/ llvm-svn: 300312
* [ORC] Re-enable the Error/Expected unit tests that were disabled in r300177.Lang Hames2017-04-141-135/+133
| | | | | | | | | | | | | The tests were failing due to an occasional deadlock in SerializationTraits for Error: Both serializers and deserializers were protected by a single mutex and in the unit test (where both ends of the RPC are in the same process) one side might obtain the mutex, then block waiting for input, leaving the other side of the connection unable to obtain the mutex to write the data the first side was waiting for. Splitting the mutex into two (one for serialization, one for deserialization) appears to have fixed the issue. llvm-svn: 300286
* Remove all allocation and divisions from GreatestCommonDivisorRichard Smith2017-04-131-0/+43
| | | | | | | | | | | Switch from Euclid's algorithm to Stein's algorithm for computing GCD. This avoids the (expensive) APInt division operation in favour of bit operations. Remove all memory allocation from within the GCD loop by tweaking our `lshr` implementation so it can operate in-place. Differential Revision: https://reviews.llvm.org/D31968 llvm-svn: 300252
* [ORC] Temporarily disable the RPC Error/Expected unit tests while I investigateLang Hames2017-04-131-133/+135
| | | | | | bot failures. llvm-svn: 300177
* [ORC] Remove more extraneous semicolons from r300167, rename the RPC ExpectedLang Hames2017-04-131-4/+4
| | | | | | tests to be consistent with the Error tests. llvm-svn: 300173
* [ORC] Add RPC and serialization support for Errors and Expecteds.Lang Hames2017-04-131-0/+192
| | | | | | | | | | | | | | This patch allows Error and Expected types to be passed to and returned from RPC functions. Serializers and deserializers for custom error types (types deriving from the ErrorInfo class template) can be registered with the SerializationTraits for a given channel type (see registerStringError in RPCSerialization.h for an example), allowing a given custom type to be sent/received. Unregistered types will be serialized/deserialized as StringErrors using the custom type's log message as the error string. llvm-svn: 300167
* [ORC] Use native Errors rather than converted std::error_codes for ORC RPC.Lang Hames2017-04-131-3/+3
| | | | llvm-svn: 300155
* Fix some ArgList uses after API change in r300135.Richard Smith2017-04-121-4/+4
| | | | llvm-svn: 300139
* [llvm-pdbdump] More advanced class definition dumping.Zachary Turner2017-04-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Previously the dumping of class definitions was very primitive, and it made it hard to do more than the most trivial of output formats when dumping. As such, we would only dump one line for each field, and then dump non-layout items like nested types and enums. With this patch, we do a complete analysis of the object hierarchy including aggregate types, bases, virtual bases, vftable analysis, etc. The only immediately visible effects of this are that a) we can now dump a line for the vfptr where before we would treat that as padding, and b) we now don't treat virtual bases that come at the end of a class as padding since we have a more detailed analysis of the class's storage usage. In subsequent patches, we should be able to use this analysis to display a complete graphical view of a class's layout including recursing arbitrarily deep into an object's base class / aggregate member hierarchy. llvm-svn: 300133
* [Support] Add support for unique_ptr<> to Casting.h.Zachary Turner2017-04-121-0/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Often you have a unique_ptr<T> where T supports LLVM's casting methods, and you wish to cast it to a unique_ptr<U>. Prior to this patch, this requires doing hacky things like: unique_ptr<U> Casted; if (isa<U>(Orig.get())) Casted.reset(cast<U>(Orig.release())); This is overly verbose, and it would be nice to just be able to use unique_ptr directly with cast and dyn_cast. To this end, this patch updates cast<> to work directly with unique_ptr<T>, so you can now write: auto Casted = cast<U>(std::move(Orig)); Since it's possible for dyn_cast<> to fail, however, we choose to use a slightly different API here, because it's awkward to write if (auto Casted = dyn_cast<U>(std::move(Orig))) {} when Orig may end up not having been moved at all. So the interface for dyn_cast is if (auto Casted = unique_dyn_cast<U>(Orig)) {} Where the inclusion of `unique` in the name of the cast operator re-affirms that regardless of success of or fail of the casting, exactly one of the input value and the return value will contain a non-null result. Differential Revision: https://reviews.llvm.org/D31890 llvm-svn: 300098
* [IR] Redesign the case iterator in SwitchInst to actually be an iteratorChandler Carruth2017-04-121-0/+63
| | | | | | | | | | | | | | | | and to expose a handle to represent the actual case rather than having the iterator return a reference to itself. All of this allows the iterator to be used with common STL facilities, standard algorithms, etc. Doing this exposed some missing facilities in the iterator facade that I've fixed and required some work to the actual iterator to fully support the necessary API. Differential Revision: https://reviews.llvm.org/D31548 llvm-svn: 300032
* MemorySSA: Move to Analysis, from Transforms/Utils. It's used asDaniel Berlin2017-04-113-3/+3
| | | | | | | | Analysis, it has Analysis passes, and once NewGVN is made an Analysis, this removes the cross dependency from Analysis to Transform/Utils. NFC. llvm-svn: 299980
* Allow DataLayout to specify addrspace for allocas.Matt Arsenault2017-04-101-1/+3
| | | | | | | | | | | | | | | | | | | | | | | LLVM makes several assumptions about address space 0. However, alloca is presently constrained to always return this address space. There's no real way to avoid using alloca, so without this there is no way to opt out of these assumptions. The problematic assumptions include: - That the pointer size used for the stack is the same size as the code size pointer, which is also the maximum sized pointer. - That 0 is an invalid, non-dereferencable pointer value. These are problems for AMDGPU because alloca is used to implement the private address space, which uses a 32-bit index as the pointer value. Other pointers are 64-bit and behave more like LLVM's notion of generic address space. By changing the address space used for allocas, we can change our generic pointer type to be LLVM's generic pointer type which does have similar properties. llvm-svn: 299888
* Fix signed / unsigned comparison warnings.Zachary Turner2017-04-101-2/+2
| | | | llvm-svn: 299873
* [Support] Add support for finding unset bits in a BitVector.Zachary Turner2017-04-101-0/+39
| | | | | | | | | | | | BitVector had methods for searching for the first and next set bits, but it did not have analagous methods for finding the first and next unset bits. This is useful when your ones and zeros are grouped together and you want to iterate over ranges of ones and zeros. Differential Revision: https://reviews.llvm.org/D31802 llvm-svn: 299857
* [ADT] Add a generic breadth-first-search graph iterator.Davide Italiano2017-04-062-0/+75
| | | | | | | | This will be used in LCSSA to speed up the canonicalization. Differential Revision: https://reviews.llvm.org/D31694 llvm-svn: 299660
* [Orc] Add missing header include for r299611.Lang Hames2017-04-061-0/+1
| | | | llvm-svn: 299623
* [Orc] Break QueueChannel out into its own header and add a utility,Lang Hames2017-04-064-83/+200
| | | | | | createPairedQueueChannels, to simplify channel creation in the RPC unit tests. llvm-svn: 299611
* [RuntimeDyld] Remove an unused static member left over from r299449.Lang Hames2017-04-051-2/+0
| | | | llvm-svn: 299497
OpenPOWER on IntegriCloud