llvm-svn: 179975

We did not terminate the switch case and we executed the search routine twice.

llvm-svn: 179974

Specifically:

1. Added checks that unwind is being properly added to various instructions.
2. Fixed the declaration/calling of objc_release to have a return type of void.
3. Moved all checks to precede the functions and added checks to ensure that the
checks would only match inside the specific function that we are attempting to
check.

llvm-svn: 179973

[objc-arc] Check that objc-arc-expand properly handles all strictly forwarding calls and does not touch calls which are not strictly forwarding (i.e. objc_retainBlock).

llvm-svn: 179972

[objc-arc] Renamed the test file clang-arc-used-intrinsic-removed-if-isolated.ll -> intrinsic-use-isolated.ll to match the other test file intrinsic-use.ll.

llvm-svn: 179971

llvm-svn: 179970

C++1y, so stop adding the 'const' there. Provide a compatibility warning for
code relying on this in C++11, with a fix-it hint. Update our lazily-written
tests to add the const, except for those ones which were testing our
implementation of this rule.

llvm-svn: 179969

When we strength reduce an objc_retainBlock call to objc_retain, increment NumPeeps and make sure that Changed is set to true.

llvm-svn: 179968

llvm-svn: 179967

llvm-svn: 179966

llvm-svn: 179965

[objc-arc] Refactored OptimizeReturns so that it uses continue instead of a large multi-level nested if statement.

llvm-svn: 179964

This will make it clearer when we are actually resetting a sequence's progress
vs just changing state. This is an important distinction because the former case
clears any pointers that we are tracking while the later does not.

llvm-svn: 179963

Still to do here:
  - we have a collection of syntactic accepts-invalids to diagnose
  - support non-PODs in VLAs, including dynamic initialization /
    destruction
  - runtime checks (and throw std::bad_array_length) for bad bound
  - support VLA capture by reference in lambdas
  - properly support VLAs in range-based for (don't recompute bound)

llvm-svn: 179962

With a little help from the frontend, it looks like the standard va_*
intrinsics can do the job.

Also clean up an old bitcast hack in LowerVAARG that dealt with
unaligned double loads. Load SDNodes can specify an alignment now.

Still missing: Calling varargs functions with float arguments.

llvm-svn: 179961

llvm-svn: 179960

llvm-svn: 179959

Add a CXXDefaultInitExpr, analogous to CXXDefaultArgExpr, and use it both in
CXXCtorInitializers and in InitListExprs to represent a default initializer.

There's an additional complication here: because the default initializer can
refer to the initialized object via its 'this' pointer, we need to make sure
that 'this' points to the right thing within the evaluation.

llvm-svn: 179958

This transformation will transform a conditional store with a preceeding
uncondtional store to the same location:

 a[i] =
 may-alias with a[i] load
 if (cond)
   a[i] = Y

into an unconditional store.

 a[i] = X
 may-alias with a[i] load
 tmp = cond ? Y : X;
 a[i] = tmp

We assume that on average the cost of a mispredicted branch is going to be
higher than the cost of a second store to the same location, and that the
secondary benefits of creating a bigger basic block for other optimizations to
work on outway the potential case were the branch would be correctly predicted
and the cost of the executing the second store would be noticably reflected in
performance.

hmmer's execution time improves by 30% on an imac12,2 on ref data sets. With
this change we are on par with gcc's performance (gcc also performs this
transformation). There was a 1.2 % performance improvement on a ARM swift chip.
Other tests in the test-suite+external seem to be mostly uninfluenced in my
experiments:
This optimization was triggered on 41 tests such that the executable was
different before/after the patch. Only 1 out of the 40 tests (dealII) was
reproducable below 100% (by about .4%). Given that hmmer benefits so much I
believe this to be a fair trade off.

I am going to watch performance numbers across the builtbots and will revert
this if anything unexpected comes up.

llvm-svn: 179957

Previously, when spilling 64-bit paired registers, an LDMIA with both
a FrameIndex and an offset was produced. This kind of instruction
shouldn't exist, and the extra operand was being confused with the
predicate, causing aborts later on.

This removes the invalid 0-offset from the instruction being
produced.

llvm-svn: 179956

llvm-svn: 179955

llvm-svn: 179954

llvm-svn: 179953

llvm-svn: 179952

llvm-svn: 179951

llvm-svn: 179950

llvm-svn: 179949

Move 'kw_align' case to proper section, reorganize function attribute keyword case statements to be consistent with r179119

llvm-svn: 179948

llvm-svn: 179947

Clarifying memory allocation: approved for C++14. Move from N/A to no, since we currently relax 'operator new' calls which didn't come from new-expressions.

llvm-svn: 179946

llvm-svn: 179945

llvm-svn: 179944

llvm-svn: 179943

llvm-svn: 179942

Implement core issue 1608: class members can be found via operator lookup in a trailing return type in that class's body.

llvm-svn: 179941

I think it's almost impossible to fold atomic fences profitably under
LLVM/C++11 semantics. As a result, this is now unused and just
cluttering up the target interface.

llvm-svn: 179940

llvm-svn: 179939

This is part of a future patch to use yamlio that incorrectly ended up in a
cleanup patch.

Thanks to Benjamin Kramer for reporting it.

llvm-svn: 179938

llvm-svn: 179937

llvm-svn: 179936