expressions.  

Previously, ClangUserExpression assumed that if
there was a constant result for an expression 
then it could be determined during parsing.  In
particular, the IRInterpreter ran while parser
state (in particular, ClangExpressionDeclMap) 
was present.  This approach is flawed, because
the IRInterpreter actually is capable of using
external variables, and hence the result might
be different each run.  Until now, we papered
over this flaw by re-parsing the expression each
time we ran it.

I have rewritten the IRInterpreter to be 
completely independent of the ClangExpressionDeclMap.
Instead of special-casing external variable lookup,
which ties the IRInterpreter closely to LLDB,
we now interpret the exact same IR that the JIT
would see.  This IR assumes that materialization
has occurred; hence the recent implementation of the
Materializer, which does not require parser state
(in the form of ClangExpressionDeclMap) to be 
present.

Materialization, interpretation, and dematerialization
are now all independent of parsing.  This means that
in theory we can parse expressions once and run them
many times.  I have three outstanding tasks before
shutting this down:

    - First, I will ensure that all of this works with
      core files.  Core files have a Process but do not
      allow allocating memory, which currently confuses
      materialization.

    - Second, I will make expression breakpoint 
      conditions remember their ClangUserExpression and
      re-use it.

    - Third, I will tear out all the redundant code
      (for example, materialization logic in
      ClangExpressionDeclMap) that is no longer used.

While implementing this fix, I also found a bug in
IRForTarget's handling of floating-point constants.  
This should be fixed.

llvm-svn: 179801

llvm-svn: 179800

llvm-svn: 179799

llvm-svn: 179798

This pattern started popping up in vectorized min/max reductions.

llvm-svn: 179797

llvm-svn: 179796

llvm-svn: 179795

-Wunitnitialized warning.

Patch by Rui Ueyama.

llvm-svn: 179794

llvm-svn: 179793

Fixed an issue where "platform process list" help message has options displayed a couple dozen times.

llvm-svn: 179792

Semantics of parameters named Index and Idx were inconsistent between
"include/llvm/IR/Attributes.h", "lib/IR/AttributeImpl.h" and
"lib/IR/Attributes.cpp": sometimes these were fixed 1-based indexes of IR
parameters (or AttributeSet::ReturnIndex for IR return values or
AttributeSet::FunctionIndex for IR functions), other times they were the
internal slot for storage in the underlying AttributeSetImpl. I renamed usage of
the former to "Index" and usage of the latter to "Slot" ("Slot" was already
being used consistently for the latter in a subset of cases)

Patch by Stephen Lin!

llvm-svn: 179791

1. Verify::VerifyParameterAttrs in "lib/IR/Verifier.cpp" and
   AttrBuilder::removeFunctionOnlyAttrs in "lib/IR/Attributes.cpp" (only called
   by Verify::VerifyFunctionAttrs) separately maintained a list of function-only
   attribute types. I've consolidated the logic into a new function used for
   both cases in "lib/IR/Verifier.cpp", so this logic is in one place (other
   than the AsmParser front-end)

2. Various functions in "lib/IR/Verifier.cpp" passed AttributeSet around by
   reference needlessly, as it's just a handle to an immutable pimpl body.

Patch by Stephen Lin!

llvm-svn: 179790

llvm-svn: 179789

Added unit tests for register read (should pass) and the expression interpreter (xfail) after the inferior has crashed.
- Thanks to Samuel Jacob for the related reproducer.

Reviewed by: Daniel Malea.

llvm-svn: 179788

Disable "source info" until actually implemented.

llvm-svn: 179787

In the function InstCombiner::visitExtractElementInst() removed the limitation that extract is promoted over a cast only if the cast has only one use.

llvm-svn: 179786

llvm-svn: 179785

Objective-C dictionary literals has bad syntax for the
separator. // rdar://10679157

llvm-svn: 179784

Added a function scalarizePHI() that sclarizes a vector phi instruction if it has only 2 uses: one to promote the vector phi in a loop and the other use is an extract operation of one element at a constant location.

llvm-svn: 179783

llvm-svn: 179782

llvm-svn: 179781

llvm-svn: 179780

Since we use C++11, we should switch over to using std::unique_ptr when C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++.

Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro.

llvm-svn: 179779

We are still able to handle mixed endian objects by swapping one struct at a
time.

llvm-svn: 179778

llvm-svn: 179777

llvm-svn: 179776

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