array of a suitable size and alignment for any of a number of different
types to be stored into the character array.

The mechanisms for producing an explicitly aligned type are fairly
complex because this operation is poorly supported on all compilers.
We've spent a fairly significant amount of time experimenting with
different implementations inside of Google, and the one using explicitly
expanded templates has been the most robust.

Credit goes to Nick Lewycky for writing the first 20 versions or so of
this logic we had inside of Google. I based this on the only one to
actually survive. In case anyone is worried, yes we are both explicitly
re-contributing and re-licensing it for LLVM. =]

Once the issues with actually specifying the alignment are finished, it
turns out that most compilers don't in turn align anything the way they
are instructed. Testing of this logic against both Clang and GCC
indicate that the alignment constraints are largely ignored by both
compilers! I've come up with and used a work-around by wrapping each
alignment-hinted type directly in a struct, and using that struct to
align the character array through a union. This elaborate hackery is
terrifying, but I've included testing that caught a terrifying number of
bugs in every other technique I've tried.

All of this in order to implement a poor C++98 programmers emulation of
C++11 unrestricted unions in classes such as SmallDenseMap.

llvm-svn: 158597

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 is now -Wunused-private-field clean except for
- lib/MC/MCDisassembler/Disassembler.h. Not sure why it keeps all those unaccessible fields.
- gtest.

llvm-svn: 158096

llvm-svn: 158046

IntegersSubsetMapping: added exclude operation, that allows to exclude subset of integers from current mapping.

llvm-svn: 157989

Changed type of Items collection: from std::vector to std::list.
Also some small fixes made in IntegersSubset.h, IntegersSubsetMapping.h and IntegersSubsetTest.cpp.

llvm-svn: 157987

- Fixed IntegersSubsetGeneric copy/assignment behaviour. 
- Fixed IntegersSubsetGeneric::getSize/getSingleValue methods.
- Fixed IntegersSubsetGeneric::verify method.

Also IntegersSubset.h and IntegersSubsetMapping.h headers was fixed.

llvm-svn: 157887

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

this fixes the missed optimization I was seeing in the CorrelatedValuePropagation pass

llvm-svn: 157032

on MIPS where they are not implemented.

llvm-svn: 156935

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: 154930

llvm-svn: 154850

through the use of 'fpmath' metadata.  Currently this only provides a 'fpaccuracy'
value, which may be a number in ULPs or the keyword 'fast', however the intent is
that this will be extended with additional information about NaN's, infinities
etc later.  No optimizations have been hooked up to this so far.

llvm-svn: 154822

llvm-svn: 154766

llvm-svn: 153977

llvm-svn: 153882

node and returning it if one didn't exist.

llvm-svn: 153798

needed for correctness, but still doesn't clean up code that now unnecessary
checks for reachability.

llvm-svn: 153755

llvm-svn: 153672

llvm-svn: 153607

(and hopefully on Windows). The bots have been down most of the day
because of this, and it's not clear to me what all will be required to
fix it.

The commits started with r153205, then r153207, r153208, and r153221.
The first commit seems to be the real culprit, but I couldn't revert
a smaller number of patches.

When resubmitting, r153207 and r153208 should be folded into r153205,
they were simple build fixes.

llvm-svn: 153241

Based on this discussion: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120305/138477.html
1. Declare a virtual function getPointerToNamedFunction() in JITMemoryManager
2. Move the implementation of getPointerToNamedFunction() form JIT/MCJIT to DefaultJITMemoryManager.

llvm-svn: 153205

llvm-svn: 152780

llvm-svn: 152703

Also refactor the existing OProfile profiling code to reuse the same interfaces with the VTune profiling code.
In addition, unit tests for the profiling interfaces were added.

This patch was prepared by Andrew Kaylor and Daniel Malea, and reviewed in the llvm-commits list by Jim Grosbach

llvm-svn: 152620