This patch changes the type used to hold the FU bitset from unsigned to uint64_t.
This will be needed for some upcoming PowerPC itineraries.

llvm-svn: 158679

llvm-svn: 158678

Patch by Mikael Lyngvig!

llvm-svn: 158677

This simplifies the code a little bit, since these functions all took a
SourceManager parameter and called a bunch of methods on it, and makes
the functions available to other users.

llvm-svn: 158676

llvm-svn: 158675

The NOP, WFE, WFI, SEV and YIELD instructions are all hints w/
a different immediate value in bits [7,0]. Define a generic HINT
instruction and refactor NOP, WFI, WFI, SEV and YIELD to be
assembly aliases of that.

rdar://11600518

llvm-svn: 158674

When returning a 'cannot match due to missing CPU features' error code,
if there are multiple potential matches with different feature sets,
return the smallest set of missing features from the alternatives as
that's most likely to be the one that's desired.

llvm-svn: 158673

llvm-svn: 158670

This exploits the relative order of the arguments and/or checks already
made in the functions.

llvm-svn: 158669

* Escaped "::" where needed to prevent Doxygen trying to make links;
* Updated one mention of C++0x to refer to C++11;
* Fixed a \brief summary to make it somewhat concise.

llvm-svn: 158667

This handles the very common case of people writing inline functions in their
main source files and not tagging them as inline. These cases should still
behave as the user intended. (The diagnostic is still emitted as an extension.)

I'm reworking this code anyway to account for C++'s equivalent restriction in
[basic.def.odr]p6, but this should get some bots back to green.

llvm-svn: 158666

// rdar://11676972

llvm-svn: 158665

Patch by Nikola Smiljanic!

llvm-svn: 158664

crash on invalid function decl with alloc_size attribute

llvm-svn: 158663

alloc_size attribute: there's nothing wrong with alloc_size(1,1). It just means the function allocates x^2 bytes. GCC also accepts this syntax

llvm-svn: 158662

Now, as long as the 'Namespaces' variable is correct inside Attr.td, the
generated code will correctly admit a C++11 attribute only when it has the
appropriate namespace(s).

llvm-svn: 158661

This metadata can be attached to any instruction returning a pointer

llvm-svn: 158660

when a compile time constant is known.  This occurs when implicitly zero 
extending function arguments from 16 bits to 32 bits.  The 8 bit case doesn't
need to be handled, as the 8 bit constants are encoded directly, thereby
not needing a separate load instruction to form the constant into a register.

<rdar://problem/11481151>

llvm-svn: 158659

llvm-svn: 158658

[TSan] kill some linux-specific code in favor of code in common runtime: reuse wrappers for mmap routines, ProcessMaps iterator, thread stack calculation

llvm-svn: 158657

temporarily reverted.

This test is annoyingly overspecified, but I don't know of another way
to thoroughly test the saving and restoring of the registers. While this
will have to be adjusted even with the issue fixed in order to re-apply
r158087, those adjustments should very clearly indicate that it is still
correct (%esp getting restored prior to pops), whereas without it, this
case can easily slip under the radar.

Still, any suggestions for improvements are very welcome.

All credit to Matt Beaumont-Gay for reducing this out of an insane
Address Sanitizer crash to a reasonably small seg-faulting C program
when built with -mstackrealign. I just reduced it to IR, which was much
simpler. =]

llvm-svn: 158656

llvm-svn: 158655

This patch causes problems when both dynamic stack realignment and
dynamic allocas combine in the same function. With this patch, we no
longer build the epilog correctly, and silently restore registers from
the wrong position in the stack.

Thanks to Matt for tracking this down, and getting at least an initial
test case to Chad. I'm going to try to check a variation of that test
case in so we can easily track the fixes required.

llvm-svn: 158654

__forceinline is a combination of the inline keyword and __attribute__((always_inline))

llvm-svn: 158653

also deal with '>>>' (in CUDA), '>=', and '>>='. Fix the FixItHints logic to
deal with cases where the token is followed by an adjacent '=', '==', '>=',
'>>=', or '>>>' token, where a naive fix-it would result in a differing token
stream on a re-lex.

llvm-svn: 158652

the member expression is in parentheses.

llvm-svn: 158651

llvm-svn: 158650

llvm-svn: 158649

llvm-svn: 158648

llvm-svn: 158647

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

We have SmallDenseMap now that has more correct and predictable
semantics, even though it is a more narrow abstraction.

llvm-svn: 158644

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

Patch by Johannes Schaub!

llvm-svn: 158643

The most important change here is that the destructor and copy
constructor for StoredDeclsList will now reliably be run. Previously,
the destructors at least were missed in some cases. See the LLVM commits
discussions for why SmallMap is broken and going away.

llvm-svn: 158642

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

implementation of the class layout for the V8 type.

llvm-svn: 158640

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

construct just for my sanity.

llvm-svn: 158637