llvm-svn: 162918

Fix another roundToIntegral bug where very large values could become infinity.  Problem and solution identified by Steve Canon.

llvm-svn: 161969

Fix a problem with APFloat::roundToIntegral where it would return incorrect results for negative inputs to trunc.  Add unit tests to verify this behavior.

llvm-svn: 161929

TinyPtrVector. With these, it is sufficiently functional for my more
normal / pedestrian uses.

I've not included some r-value reference stuff here because the value
type for a TinyPtrVector is, necessarily, just a pointer.

I've added tests that cover the basic behavior of these routines, but
they aren't as comprehensive as I'd like. In particular, they don't
really test the iterator semantics as thoroughly as they should. Maybe
some brave soul will feel enterprising and flesh them out. ;]

llvm-svn: 161104

re-use allocated vectors as much as possible.

llvm-svn: 161041

for this class. These tests exercise most of the basic properties, but
the API for TinyPtrVector is very strange currently. My plan is to start
fleshing out the API to match that of SmallVector, but I wanted a test
for what is there first.

Sadly, it doesn't look reasonable to just re-use the SmallVector tests,
as this container can only ever store pointers, and much of the
SmallVector testing is to get construction and destruction right.

Just to get this basic test working, I had to add value_type to the
interface.

While here I found a subtle bug in the combination of 'erase', 'begin',
and 'end'. Both 'begin' and 'end' wanted to use a null pointer to
indicate the "end" iterator of an empty vector, regardless of whether
there is actually a vector allocated or the pointer union is null.
Everything else was fine with this except for erase. If you erase the
last element of a vector after it has held more than one element, we
return the end iterator of the underlying SmallVector which need not be
a null pointer. Instead, simply use the pointer, and poniter + size()
begin/end definitions in the tiny case, and delegate to the inner vector
whenever it is present.

llvm-svn: 161024

test more than a single instantiation of SmallVector.

Add testing for 0, 1, 2, and 4 element sized "small" buffers. These
appear to be essentially untested in the unit tests until now.

Fix several tests to be robust in the face of a '0' small buffer. As
a consequence of this size buffer, the growth patterns are actually
observable in the test -- yes this means that many tests never caused
a grow to occur before. For some tests I've merely added a reserve call
to normalize behavior. For others, the growth is actually interesting,
and so I captured the fact that growth would occur and adjusted the
assertions to not assume how rapidly growth occured.

Also update the specialization for a '0' small buffer length to have all
the same interface points as the normal small vector.

llvm-svn: 161001

Makefiles, the CMake files in every other part of the LLVM tree, and
sanity.

This should also restore the output tree structure of all the unit
tests, sorry for breaking that, and thanks for letting me know.

The fundamental change is to put a CMakeLists.txt file in the unittest
directory, with a single test binary produced from it. This has several
advantages:

- No more weird directory stripping in the unittest macro, allowing it
  to be used more readily in other projects.
- No more directory prefixes on all the source files.
- Allows correct and precise use of LLVM's per-directory dependency
  system.
- Allows use of the checking logic for source files that have not been
  added to the CMake build. This uncovered a file being skipped with
  CMake in LLVM and one in Clang's unit tests.
- Makes Specifying conditional compilation or other custom logic for JIT
  tests easier.

It did require adding the concept of an explicit 'optional' source file
to the CMake build so that the missing-file check can skip cases where
the file is *supposed* to be missing. =]

This is another chunk of refactoring the CMake build in order to make it
usable for other clients like CompilerRT / ASan / TSan.

Note that this is interdependent with a Clang CMake change.

llvm-svn: 158909

StringMap suffered from the same bug as DenseMap: when you explicitly
construct it with a small number of buckets, you can arrange for the
tombstone-based growth path to be followed when the number of buckets
was less than '8'. In that case, even with a full map, it would compare
'0' as not less than '0', and refuse to grow the table, leading to
inf-loops trying to find an empty bucket on the next insertion. The fix
is very simple: use '<=' as the comparison. The same fix was applied to
DenseMap as well during its recent refactoring.

Thanks to Alex Bolz for the great report and test case. =]

llvm-svn: 158725

GoogleTest already prints errors with all the information about which
test case contained the error.

llvm-svn: 158724

I don't know how useful these are for SmallDenseMap, I'll leave that decision to Chandler.

llvm-svn: 158646

It always returns the iterator for the first inserted element, or the passed in
iterator if the inserted range was empty. Flesh out the unit test more and fix
all the cases it uncovered so far.

llvm-svn: 158645

SmallVector: return a valid iterator for the rare case of inserting an empty range into a SmallVector.

Patch by Johannes Schaub!

llvm-svn: 158643

SmallDenseMap::swap.

First, make it parse cleanly. Yay for uninstantiated methods.

Second, make the inline-buckets case work correctly. This is way
trickier than it should be due to the uninitialized values in empty and
tombstone buckets.

Finally fix a few typos that caused construction/destruction mismatches
in the counting unittest.

llvm-svn: 158641

destruction and fix a bug in SmallDenseMap they caught.

This is kind of a poor-man's version of the testing that just adds the
addresses to a set on construction and removes them on destruction. We
check that double construction and double destruction don't occur.
Amusingly enough, this is enough to catch a lot of SmallDenseMap issues
because we spend a lot of time with fixed stable addresses in the inline
buffer.

The SmallDenseMap bug fix included makes grow() not double-destroy in
some cases. It also fixes a FIXME there, the code was pretty crappy. We
now don't have any wasted initialization, but we do move the entries in
inline bucket array an extra time. It's probably a better tradeoff, and
is much easier to get correct.

llvm-svn: 158639

implementation.

This type includes an inline bucket array which is used initially. Once
it is exceeded, an array of 64 buckets is allocated on the heap. The
bucket count grows from there as needed. Some highlights of this
implementation:

- The inline buffer is very carefully aligned, and so supports types
  with alignment constraints.
- It works hard to avoid aliasing issues.
- Supports types with non-trivial constructors, destructors, copy
  constructions, etc. It works reasonably hard to minimize copies and
  unnecessary initialization. The most common initialization is to set
  keys to the empty key, and so that should be fast if at all possible.

This class has a performance / space trade-off. It tries to optimize for
relatively small maps, and so packs the inline bucket array densely into
the object. It will be marginally slower than a normal DenseMap in a few
use patterns, so it isn't appropriate everywhere.

The unit tests for DenseMap have been generalized a bit to support
running over different map implementations in addition to different
key/value types. They've then been automatically extended to cover the
new container through the magic of GoogleTest's typed tests.

All of this is still a bit rough though. I'm going to be cleaning up
some aspects of the implementation, documenting things better, and
adding tests which include non-trivial types. As soon as I'm comfortable
with the correctness, I plan to switch existing users of SmallMap over
to this class as it is already more correct w.r.t. construction and
destruction of objects iin the map.

Thanks to Benjamin Kramer for all the reviews of this and the lead-up
patches. That said, more review on this would really be appreciated. As
I've noted a few times, I'm quite surprised how hard it is to get the
semantics for a hashtable-based map container with a small buffer
optimization correct. =]

llvm-svn: 158638

Merge the SmallBitVector and BitVector unit tests with gtest's typed test magic and bring SmallBitVector up to date.

llvm-svn: 158600

of typename. GCC and Clang were fine with this, but MSVC won't accept
it. Fortunately, it also doesn't need it. Yuck.

Thanks to Nakamura for pointing this out in IRC.

llvm-svn: 158593

These were already trying to be type parameterized over different
key/value pairs. I've realized this goal using GoogleTest's typed test
functionality. This allows us to easily replicate the tests across
different key/value combinations and soon different mapping templates.

I've fixed a few bugs in the tests and extended them a bit in the
process as many tests were only applying to the int->int mapping.

llvm-svn: 158589

llvm-svn: 157885

This back-end was deprecated in favor of the NVPTX back-end.

NV_CONTRIB

llvm-svn: 157417

based on a patch by Preston Briggs, with some modifications

llvm-svn: 157231

llvm-svn: 156812

llvm-svn: 156810

Returning a temporary BitVector is very expensive. If you must, create
the temporary explicitly: Use BitVector(A).flip() instead of ~A.

llvm-svn: 156768

The existing operation (A & B).any() is very slow.

llvm-svn: 156760

llvm-svn: 156652

llvm-svn: 156507

llvm-svn: 155791

Fixed SmallMap test. The order of items is undefined in DenseMap. So being checking the increment for big mode, we can only check that all items are in map.

llvm-svn: 155651

Comparing ~0UL with an unsigned will always return false when long is 64 bits long.

llvm-svn: 155568

This reverts commit 76271a3366731d4c372fdebcd8d3437e6e09a61b.

as it's breaking the bots.

llvm-svn: 155562

- FlatArrayMap. Very simple map container that uses flat array inside.
- MultiImplMap. Map container interface, that has two modes, one for small amount of elements and one for big amount.
- SmallMap. SmallMap is DenseMap compatible MultiImplMap. It uses FlatArrayMap for small mode, and DenseMap for big mode. 

Also added unittests for new classes and update for ProgrammersManual.
For more details about new classes see ProgrammersManual and comments in sourcecode.

llvm-svn: 155557

This nicely handles the most common case of virtual register sets, but
also handles anticipated cases where we will map pointers to IDs.

The goal is not to develop a completely generic SparseSet
template. Instead we want to handle the expected uses within llvm
without any template antics in the client code. I'm adding a bit of
template nastiness here, and some assumption about expected usage in
order to make the client code very clean.

The expected common uses cases I'm designing for:
- integer keys that need to be reindexed, and may map to additional
  data
- densely numbered objects where we want pointer keys because no
  number->object map exists.

llvm-svn: 155227

llvm-svn: 153882

llvm-svn: 152522

it would fail with {,u}int64_t on x86-64 Linux.

This also removes code duplication.

llvm-svn: 152517

integral and enumeration types. This is accomplished with a bit of
template type trait magic. Thanks to Richard Smith for the core idea
here to detect viable types by detecting the set of types which can be
default constructed in a template parameter.

This is used (in conjunction with a system for detecting nullptr_t
should it exist) to provide an is_integral_or_enum type trait that
doesn't need a whitelist or direct compiler support.

With this, the hashing is extended to the more general facility. This
will be used in a subsequent commit to hashing more things, but I wanted
to make sure the type trait magic went through the build bots separately
in case other compilers don't like this formulation.

llvm-svn: 152217

SmallPtrSet: Provide a more efficient implementation of swap than the default triple-copy std::swap.

This currently assumes that both sets have the same SmallSize to keep the implementation simple,
a limitation that can be lifted if someone cares.

llvm-svn: 152143

llvm-svn: 152003