llvm-svn: 179775

In X86FastISel::X86SelectStore(), improperly aligned stores are rejected and
handled by the DAG-based ISel.  However, X86FastISel::X86SelectLoad() makes
no such requirement.  There doesn't appear to be an x86 architectural
correctness issue with allowing potentially unaligned store instructions.
This patch removes this restriction.

Patch by Jim Stichnot.

llvm-svn: 179774

A min/max operation is represented by a select(cmp(lt/le/gt/ge, X, Y), X, Y)
sequence in LLVM. If we see such a sequence we can treat it just as any other
commutative binary instruction and reduce it.

This appears to help bzip2 by about 1.5% on an imac12,2.

radar://12960601

llvm-svn: 179773

Re-enable m_private_run_lock changes from 179329, but only for Apple hosted builds so it doesn't break the buildbots. We will try and work the issues out in the Apple build before enabling this feature for everyone.

llvm-svn: 179772

This was a suggestion by Jordan Rose since the documented format for these pragmas is without the parentheses.  At the same time, I've increased test coverage too for the preprocessed output.

llvm-svn: 179771

llvm-svn: 179770

Patch by Doug.
rdar://13684618

llvm-svn: 179769

llvm-svn: 179768

The analyzer uses LazyCompoundVals to represent rvalues of aggregate types,
most importantly structs and arrays. This allows us to efficiently copy
around an entire struct, rather than doing a memberwise load every time a
struct rvalue is encountered. This can also keep memory usage down by
allowing several structs to "share" the same snapshotted bindings.

However, /lookup/ through LazyCompoundVals can be expensive, especially
since they can end up chaining back to the original value. While we try
to reuse LazyCompoundVals whenever it's safe, and cache information about
this transitivity, the fact is it's sometimes just not a good idea to
perpetuate LazyCompoundVals -- the tradeoffs just aren't worth it.

This commit changes RegionStore so that binding a LazyCompoundVal to struct
will do a memberwise copy if the struct is simple enough. Today's definition
of "simple enough" is "up to N scalar members" (see below), but that could
easily be changed in the future. This is enough to bring the test case in
PR15697 back down to a manageable analysis time (within 20% of its original
time, in an unfair test where the new analyzer is not compiled with LTO).

The actual value of "N" is controlled by a new -analyzer-config option,
'region-store-small-struct-limit'. It defaults to "2", meaning structs with
zero, one, or two scalar members will be considered "simple enough" for
this code path.

It's worth noting that a more straightforward implementation would do this
on load, not on bind, and make use of the structure we already have for this:
CompoundVal. A long time ago, this was actually how RegionStore modeled
aggregate-to-aggregate copies, but today it's only used for compound literals.
Unfortunately, it seems that we've special-cased LazyCompoundVal in certain
places (such as liveness checks) but failed to similarly special-case
CompoundVal in all of them. Until we're confident that CompoundVal is
handled properly everywhere, this solution is safer, since the entire
optimization is just an implementation detail of RegionStore.

<rdar://problem/13599304>

llvm-svn: 179767

A C++ overloaded operator may be implemented as an instance method, and
that instance method may be called on an rvalue object, which has no
associated region. The analyzer handles this by creating a temporary region
just for the evaluation of this call; however, it is possible that /by
creating the region/, the analyzer ends up in a previously-explored state.
In this case we don't need to continue along this path.

This doesn't actually show any behavioral change now, but it starts being
used with the next commit and prevents an assertion failure there.

llvm-svn: 179766

llvm-svn: 179765

llvm-svn: 179764

Patch by Stephen Lin

llvm-svn: 179763

llvm-svn: 179762

llvm-svn: 179761

After years of telling people: 'If you ever find any of my code that self-move-assigns, send me a bug report.' Somebody finally took me up on it.  vector::erase(begin(), begin()) does a self-move-assign of every element in the vector, leaving all of those elements in an unspecified state.  I checked the other containers for this same bug and did not find it.  Added test case.

llvm-svn: 179760

in order to prevent consistent hangs on all 3 LLDB buildbots.

llvm-svn: 179759

Patch by Jochen Eisinger.

llvm-svn: 179758

Fixes PR15748.

llvm-svn: 179757

Fixes PR15759.

llvm-svn: 179756

llvm-svn: 179755

llvm-svn: 179754

llvm-svn: 179753

llvm-svn: 179751

It is causing stage2 builds to fail, let's get them running again.

llvm-svn: 179750

llvm-svn: 179749

Simplify:
(select (icmp eq (and X, C1), 0), Y, (or Y, C2))

Into:
(or (shl (and X, C1), C3), y)

Where:
C3 = Log(C2) - Log(C1)

If:
C1 and C2 are both powers of two

llvm-svn: 179748

[objc-arc] Do not mismatch up retains inside a for loop with releases outside said for loop in the presense of differing provenance caused by escaping blocks.

This occurs due to an alloca representing a separate ownership from the
original pointer. Thus consider the following pseudo-IR:

  objc_retain(%a)
  for (...) {
    objc_retain(%a)
    %block <- %a
    F(%block)
    objc_release(%block)
  }
  objc_release(%a)

From the perspective of the optimizer, the %block is a separate
provenance from the original %a. Thus the optimizer pairs up the inner
retain for %a and the outer release from %a, resulting in segfaults.

This is fixed by noting that the signature of a mismatch of
retain/releases inside the for loop is a Use/CanRelease top down with an
None bottom up (since bottom up the Retain-CanRelease-Use-Release
sequence is completed by the inner objc_retain, but top down due to the
differing provenance from the objc_release said sequence is not
completed). In said case in CheckForCFGHazards, we now clear the state
of %a implying that no pairing will occur.

Additionally a test case is included.

rdar://12969722

llvm-svn: 179747

llvm-svn: 179746

Streamline arc-annotation test (removing some cases which do not add any extra coverage) and set it up to use FileCheck variables to make the test more robust.

llvm-svn: 179745

Fixes PR13580. Patch by Serge Pavlov!

llvm-svn: 179743

with the silence fix-it comes first.  This is more consistent with the rest
of the warnings in -Wparentheses.

llvm-svn: 179742

llvm-svn: 179741

llvm-svn: 179740

llvm-svn: 179739

Fixed a few m_private_run_lock issues when attaching and also fixed the process to not try to restart the process if the process is exited, crashed or detached. Partial patch from Carlo Kok.

llvm-svn: 179738

This patch should not have any functional changes. 

llvm-svn: 179737

In the committed example, we now see a note that tells us when the pointer
was assumed to be null.

This is the only case in which getDerefExpr returned null (failed to get
the dereferenced expr) throughout our regression tests. (There were multiple
occurrences of this one.)

llvm-svn: 179736

It's sometimes beneficial to emit a testcase with the old style attribute
syntax. Allow someone to do this.
<rdar://problem/13563209>

llvm-svn: 179735

[analyzer] Improve dereferenced expression tracking for MemberExpr with a dot and non-reference base

llvm-svn: 179734