llvm-svn: 151921

No, really, make doesn't work with spaces.

llvm-svn: 151920

This could probably be made a lot smarter, but this is a common case and doesn't require LVI to scan a lot
of code. With this change CVP can optimize away the "shift == 0" case in Hashing.h that only gets hit when
"shift" is in a range not containing 0.

llvm-svn: 151919

Hashing: microoptimize a truncate on 64 bit away. This currently blocks dead code eliminating the conditional.

The optimizer should handle this eventually, but currently LVI isn't really designed for this kind of stuff.

llvm-svn: 151918

llvm-svn: 151917

llvm-svn: 151916

llvm-svn: 151915

llvm-svn: 151914

llvm-svn: 151913

llvm-svn: 151912

llvm-svn: 151911

llvm-svn: 151910

llvm-svn: 151909

llvm-svn: 151908

llvm-svn: 151907

llvm-svn: 151906

llvm-svn: 151905

llvm-svn: 151904

llvm-svn: 151903

llvm-svn: 151902

llvm-svn: 151901

llvm-svn: 151900

This allows us to remove a lot of redundant parameters.

llvm-svn: 151899

llvm-svn: 151898

llvm-svn: 151897

llvm-svn: 151896

llvm-svn: 151895

llvm-svn: 151894

Suggested by: Sebastian Pop  <sebpop@gmail.com>

llvm-svn: 151893

folks who know something about PPC tell me that the byte swap is crazy
fast and without this the bit mixture would actually be different. It
might not be worse, but I've not measured it and so I'd rather not trust
it. This way, the algorithm is identical on both endianness hosts. I'll
look into any performance issues etc stemming from this.

llvm-svn: 151892

just ensure that the number of bytes in the pair is the sum of the bytes
in each side of the pair. As long as thats true, there are no extra
bytes that might be padding.

Also add a few tests that previously would have slipped through the
checking. The more accurate checking mechanism catches these and ensures
they are handled conservatively correctly.

Thanks to Duncan for prodding me to do this right and more simply.

llvm-svn: 151891

try to define C++ keywords as typedefs (fixed in Solaris 11).

llvm-svn: 151890

Unconditionally define __C99FEATURES__ when using C++ on Solaris.  This is a
(hopefully temporary) work around for libc++ exposing C99-but-not-C++98
features in C++98 mode.

llvm-svn: 151889

llvm-svn: 151888

This change replaces getTypeStoreSize with getTypeAllocSize in AddressSanitizer
instrumentation for stack allocations.

One case where old behaviour produced undesired results is an optimization in
InstCombine pass (PromoteCastOfAllocation), which can replace  alloca(T) with
alloca(S), where S has the same AllocSize, but a smaller StoreSize. Another
case is memcpy(long double => long double), where ASan will poison bytes 10-15
of a stack-allocated long double (StoreSize  10, AllocSize 16,
sizeof(long double) = 16).

See http://llvm.org/bugs/show_bug.cgi?id=12047 for more context.

llvm-svn: 151887

llvm-svn: 151886

for 32-bit builds in here.

llvm-svn: 151885

offsetof buildbot errors to go away...

llvm-svn: 151884

hashable data. This matters when we have pair<T*, U*> as a key, which is
quite common in DenseMap, etc. To that end, we need to detect when this
is safe. The requirements on a generic std::pair<T, U> are:

1) Both T and U must satisfy the existing is_hashable_data trait. Note
   that this includes the requirement that T and U have no internal
   padding bits or other bits not contributing directly to equality.
2) The alignment constraints of std::pair<T, U> do not require padding
   between consecutive objects.
3) The alignment constraints of U and the size of T do not conspire to
   require padding between the first and second elements.

Grow two somewhat magical traits to detect this by forming a pod
structure and inspecting offset artifacts on it. Hopefully this won't
cause any compilers to panic.

Added and adjusted tests now that pairs, even nested pairs, are treated
as just sequences of data.

Thanks to Jeffrey Yasskin for helping me sort through this and reviewing
the somewhat subtle traits.

llvm-svn: 151883

an open question of whether we can do better than this by treating pairs
as boring data containers and directly hashing the two subobjects. This
at least makes the API reasonable.

In order to make this change, I reorganized the header a bit. I lifted
the declarations of the hash_value functions up to the top of the header
with their doxygen comments as these are intended for users to interact
with. They shouldn't have to wade through implementation details. I then
defined them at the very end so that they could be defined in terms of
hash_combine or any other hashing infrastructure.

Added various pair-hashing unittests.

llvm-svn: 151882