If getElementPtr uses a constant as base pointer, then make the constant opaque.
This prevents constant folding it with the offset. The offset can usually be
encoded in the load/store instruction itself and the base address doesn't have
to be rematerialized several times.

llvm-svn: 204739

The cost for the first four stackmap operands was always TCC_Free.
This is only true for the first two operands. All other operands
are TCC_Free if they are within 64bit.

llvm-svn: 204738

Usually opaque constants shouldn't be folded, unless they are simple unary
operations that don't create new constants. Although this shouldn't drop the
opaque constant flag. This commit fixes this.

Related to <rdar://problem/14774662>

llvm-svn: 204737

llvm-svn: 204736

This used to resort to splitting the 256-bit operation into two 128-bit
shuffles and then recombining the results.

Fixes <rdar://problem/16167303>

llvm-svn: 204735

I found three implementations of this.  This splits it out into a new function
and uses it from the three places.

My plan is to add a fourth use when lowering a vector_shuffle:v16i16.

Compared the assembly output of test/CodeGen/X86 before and after.

The only change is due to how the first PSHUFB was generated in
LowerVECTOR_SHUFFLEv8i16.  If the shuffle mask specified undef (i.e. -1), the
old implementation would write -1 * 2 and -1 * 2 + 1 (254 and 255) in the
control mask.  Now we write 0x80.  These are of course interchangeable since
bit 7 decides if a constant zero is written in the result byte.  The other
instances of this code use 0x80 consistently.

Related to <rdar://problem/16167303>

llvm-svn: 204734

Summary:
Previously the code didn't check if the before and after types for the
store were pointers to different address spaces. This resulted in
instcombine using a bitcast to convert between pointers to different
address spaces, causing an assertion due to the invalid cast.

It is not be appropriate to use addrspacecast this case because it is
not guaranteed to be a no-op cast. Instead bail out and do not do the
transformation.

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D3117

llvm-svn: 204733

No functionality change.

llvm-svn: 204732

PR19187.

llvm-svn: 204731

A refinement of r198953 to handle cases where an object is accessed both through
a property getter and through direct ivar access. An object accessed through a
property should always be treated as +0, i.e. not owned by the caller. However,
an object accessed through an ivar may be at +0 or at +1, depending on whether
the ivar is a strong reference. Outside of ARC, we don't have that information,
so we just don't track objects accessed through ivars.

With this change, accessing an ivar directly will deliberately override the +0
provided by a getter, but only if the +0 hasn't participated in other retain
counting yet. That isn't perfect, but it's already unusual for people to be
mixing property access with direct ivar access. (The primary use case for this
is in setters, init methods, and -dealloc.)

Thanks to Ted for spotting a few mistakes in private review.

<rdar://problem/16333368>

llvm-svn: 204730

This is supposed to have the same store size and alignment as <4 x i32>,
but currently is split into a 64-bit and 32-bit store.

llvm-svn: 204729

If we have a loop of the form
for (unsigned n = 0; n != (k & -32); n += 32) {}
then we know that n is always divisible by 32 and the loop must
terminate. Even if we have a condition where the loop counter will
overflow it'll always hold this invariant.

PR19183. Our loop vectorizer creates this pattern and it's also
occasionally formed by loop counters derived from pointers.

llvm-svn: 204728

If GT/UGT or LT/ULT were set to expand, a comparison
with a constant would replace it with the illegal
cond code.

There are several more places later in this function that
will have the same basic problem.

Theoretically R600 should hit this problem for a test,
but for some reason it doesn't.

llvm-svn: 204727

We explicitly specifying all filenames instead of assuming some naming
convention used by clang and opt.

Contributed-by: Johannes Doerfert <doerfert@cs.uni-saarland.de>
llvm-svn: 204726

"Running multithreaded with n threads (from LLDB_TEST_THREADS)" is
incorrect in the common case, because the thread count is now obtained
from a --threads option, or a default of multiprocessing.cpu_count().

I left the messages in for now as there are some intermittent issues
that happen while running tests multithreaded and it may help in
triaging those.  We may wish to just remove them later on.

llvm-svn: 204725

to remove redundant wording, which required no changes to libc++. 2075 was a 
rewrite of the requirements for forward progress, and again, requires no changes
to the library.

llvm-svn: 204724

llvm-svn: 204723

Two DynTypedNodes can be equal if they do not have the same node type,
because DynTypedNodes for the same underlying object might have been
created from different types (for example, Decl vs VarDecl).

llvm-svn: 204722

This may or may not fix the bots. R204720 did not.

llvm-svn: 204721

This may or may not fix the bots.

llvm-svn: 204720

It is impossible to create a hard link to a non existing file, so create a
dummy file, create the link an delete the dummy file.

On windows one cannot remove the current directory, so chdir first.

llvm-svn: 204719

llvm-svn: 204718

Fixed in r204716.

llvm-svn: 204717

Some bits of select result may be initialized even if select condition
is not.

https://code.google.com/p/memory-sanitizer/issues/detail?id=50

llvm-svn: 204716

llvm-svn: 204715

Differential Revision: http://llvm-reviews.chandlerc.com/D3171

llvm-svn: 204714

llvm-svn: 204713

llvm-svn: 204712

Summary:
Remove the XFAIL added in my previous commit and correct the test such that
it correctly tests the expansion of the assembler temporary.

Also added a test to check that $at is always $1 when written by the
user.

Corrected the new assembler temporary warnings so that they are emitted for
numeric registers too.

Differential Revision: http://llvm-reviews.chandlerc.com/D3169

llvm-svn: 204711

Summary:
The assembler temporary is normally $at ($1) but can be reassigned using
'.set at=$reg'. Regardless of which register is nominated as the assembler
temporary, $at remains $1 when written by the user.

Adds warnings under the following conditions:
* The register nominated as the assembler temporary is used by the user.
* '.set noat' is in effect and $at is used by the user.
Both of these only work for named registers. I have a follow up commit that makes it work for numeric registers as well.

XFAIL set-at-directive.s since it incorrectly tests that $at is redefined by
'.set at=$reg'. Testcases will follow in a separate commit.

Patch by David Chisnall
His work was sponsored by: DARPA, AFRL

Differential Revision: http://llvm-reviews.chandlerc.com/D3167

llvm-svn: 204710

Before:
  STATIC_ASSERT((a &b) == 0);

After:
  STATIC_ASSERT((a & b) == 0);

llvm-svn: 204709

llvm-svn: 204708

llvm-svn: 204707

but keep the MSVC11 (Visual C++ 2012) support.

llvm-svn: 204706

GCC 4.0.1 and Xcode 2 are no longer supported for building llvm/clang.

llvm-svn: 204705

it has no value for us.

llvm-svn: 204704

This is a pretty straight forward translation for COFF, we just need to
stick the data in a COMDAT section marked as
IMAGE_COMDAT_SELECT_NODUPLICATES.

N.B. We must be careful to avoid sticking entities with private linkage
in COMDAT groups.  COFF is pretty hostile to the renaming of entities so
we must be careful to disallow GlobalVariables with unstable names.

llvm-svn: 204703

Based on code review feedback from Eric in r204672.

llvm-svn: 204702

Thanks to gix for pointing out that the CHECK-LABEL lines were incorrect!

llvm-svn: 204700

Extracts coming from phis were being hoisted, while all others were
sunk to their uses. This was inconsistent and didn't seem to serve a
purpose. Changing all extracts to be sunk to uses is a prerequisite
for adding block frequency to the SLP vectorizer's cost model.

I benchmarked the change in isolation (without block frequency). I
only saw noise on x86 and some potentially significant improvements on
ARM. No major regressions is good enough for me.

llvm-svn: 204699