when other cases get added.

llvm-svn: 204751

that call debug-information intrinsics.

llvm-svn: 204750

This change makes significant improvements in the performance of
calculating a UUID within ObjectFileELF, and handles both running
processes and core files correctly. This does lazy evaluation of
UUID generation and caches the result when calculated.

Change by Piotr Rak.

llvm-svn: 204749

Although the first two operands are the ones that can be swapped, the tied
input operand is listed before them, so we need to adjust for that.

I have a test case for this, but it goes along with an upcoming commit (so it
will come soon).

llvm-svn: 204748

Also added 'import sys' on some tests that are using non-standard
unittest2.skipUnless blocks with code that is intended to do things
that we have more specializes @* attributes for.  These skip
conditions were failing to execute due to missing import, causing
darwin-only tests to run on Linux regardless.  Will file a bug for
that separately.

llvm-svn: 204747

TableGen will create a lookup table for the A-type FMA instructions providing
their corresponding M-form opcodes. This will be used by upcoming commits.

llvm-svn: 204746

When there was no process, the expression options were set to not ignore breakpoints. This causes debug info to be generated and causes errors when evaluating simple expressions.

llvm-svn: 204745

Fixes PR19240.  In retrospect, this is a fairly obvious bug.  :)

llvm-svn: 204744

Remove handling of select_cc, since it makes no sense to be there. This
now does nothing, but I'll be adding some handling of other target nodes
soon.

llvm-svn: 204743

Fix an logic error in the clang driver preventing crtfastmath.o from linking when -Ofast is used without -ffast-math

In gcc using -Ofast forces linking of crtfastmath.o.
In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it).
My patch fixes inconsistency with gcc behaviour and also introduces few tests on it.

Patch by Zinovy Nis!

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

llvm-svn: 204742

Implement Pass::releaseMemory() in BlockFrequencyInfo and
MachineBlockFrequencyInfo.  Just delete the private implementation when
not in use.  Switch to a std::unique_ptr to make the logic more clear.

<rdar://problem/14292693>

llvm-svn: 204741

<rdar://problem/14292693>

llvm-svn: 204740

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