llvm-svn: 154791

The result of the Microsoft __uuidof operator must be considered a global lvalue during constant expression evaluation.
Otherwise we would get this error in C++11 mode (because of a recent change):
   error: non-type template argument of type 'const _GUID *' is not a constant expression

For code like:
template <const GUID* g = &__uuidof(struct_with_uuid)>
class COM_CLASS { };

llvm-svn: 154790

llvm-svn: 154789

llvm-svn: 154788

llvm-svn: 154787

llvm-svn: 154786

llvm-svn: 154785

includes a patch from Matthias Kleine with a regression testcase!

Adds a new iterator 'data_iterator' to OnDiskHashTable which doesn't try to
reconstruct the external_key from the internal_key, which is useful for traits
that don't store enough information to do that mapping in their key. Also
deletes the 'item_iterator' from OnDiskHashTable as dead code.

llvm-svn: 154784

This is a complex change that resulted from a great deal of
experimentation with several different benchmarks. The one which proved
the most useful is included as a test case, but I don't know that it
captures all of the relevant changes, as I didn't have specific
regression tests for each, they were more the result of reasoning about
what the old algorithm would possibly do wrong. I'm also failing at the
moment to craft more targeted regression tests for these changes, if
anyone has ideas, it would be welcome.

The first big thing broken with the old algorithm is the idea that we
can take a basic block which has a loop-exiting successor and a looping
successor and use the looping successor as the layout top in order to
get that particular block to be the bottom of the loop after layout.
This happens to work in many cases, but not in all.

The second big thing broken was that we didn't try to select the exit
which fell into the nearest enclosing loop (to which we exit at all). As
a consequence, even if the rotation worked perfectly, it would result in
one of two bad layouts. Either the bottom of the loop would get
fallthrough, skipping across a nearer enclosing loop and thereby making
it discontiguous, or it would be forced to take an explicit jump over
the nearest enclosing loop to earch its successor. The point of the
rotation is to get fallthrough, so we need it to fallthrough to the
nearest loop it can.

The fix to the first issue is to actually layout the loop from the loop
header, and then rotate the loop such that the correct exiting edge can
be a fallthrough edge. This is actually much easier than I anticipated
because we can handle all the hard parts of finding a viable rotation
before we do the layout. We just store that, and then rotate after
layout is finished. No inner loops get split across the post-rotation
backedge because we check for them when selecting the rotation.

That fix exposed a latent problem with our exitting block selection --
we should allow the backedge to point into the middle of some inner-loop
chain as there is no real penalty to it, the whole point is that it
*won't* be a fallthrough edge. This may have blocked the rotation at all
in some cases, I have no idea and no test case as I've never seen it in
practice, it was just noticed by inspection.

Finally, all of these fixes, and studying the loops they produce,
highlighted another problem: in rotating loops like this, we sometimes
fail to align the destination of these backwards jumping edges. Fix this
by actually walking the backwards edges rather than relying on loopinfo.

This fixes regressions on heapsort if block placement is enabled as well
as lots of other cases where the previous logic would introduce an
abundance of unnecessary branches into the execution.

llvm-svn: 154783

llvm-svn: 154782

llvm-svn: 154781

Spacing fixes and 80 column fixes. Use 0 instead of 0x80 for undef indices in vpermps/vpermd. Hardware only looks at lower 3-bits.

llvm-svn: 154780

llvm-svn: 154779

llvm-svn: 154778

Change _mm256_permute4x64_epi64 and _mm256_permute4x64_pd to use builtin_shufflevector instead of specific builtins. Old builtins will be removed from llvm now that vpermq/vpermpd are supported by shuffle lowering code.

llvm-svn: 154777

Passing -verify to clang without -cc1 or -Xclang silently passes (with a
printed warning, but lit doesn't care about that). This change adds -cc1 or,
as is necessary in one case, -Xclang to fix this so that these tests are
actually verifying as intended.

I'd like to change the driver so this kind of mistake could not be made, but
I'm not entirely sure how. Further, since the driver only warns about unknown
flags in general, we could have similar bugs with a misspellings of arguments
that would be nice to find.

llvm-svn: 154776

Make member variables of AsmToken private. Remove unnecessary forward declarations. Remove an unnecessary include.

llvm-svn: 154775

llvm-svn: 154774

llvm-svn: 154773

Patch by nobled <nobled@dreamwidth.org>

llvm-svn: 154772

llvm-svn: 154771

Use non-vex instructions for SSE4.

llvm-svn: 154770

llvm-svn: 154769

llvm-svn: 154767

llvm-svn: 154766

As an example, attach range info to the "invalid instruction" message:

$ clang -arch arm -c asm.c
asm.c:2:11: error: invalid instruction
  __asm__("foo r0");
          ^
<inline asm>:1:2: note: instantiated into assembly here
        foo r0
        ^~~

llvm-svn: 154765

llvm-svn: 154764

It would be nice to use OwningPtr here, but DeclContextInfo is stored in a DenseMap.

llvm-svn: 154763

llvm-svn: 154762

llvm-svn: 154761

llvm-svn: 154760

llvm-svn: 154759

llvm-svn: 154758

llvm-svn: 154757

initialize an array of unsigned char. Outside C++11 mode, this bug was benign,
and just resulted in us emitting a constant which was double the required
length, padded with 0s. In C++11, it resulted in us generating an array whose
first element was something like  i8 ptrtoint ([n x i8]* @str to i8).

llvm-svn: 154756

llvm-svn: 154755

by Sundeep Kushwaha.

llvm-svn: 154754

definition for protocols static. // rdar://11248048

llvm-svn: 154753

llvm-svn: 154752

A patch by Sean McBride.

llvm-svn: 154751