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

Avoids a couple of copies and allows more flexibility in the clients.

llvm-svn: 179935

Sourcery CodeBench and modern FSF Mips toolchains require a bit more
complicated algorithm to calculate headers, libraries and sysroot paths
than implemented by Clang driver now. The main problem is that all these
paths depend on a set of command line arguments additionally to a target
triple value. For example, let $TC is a toolchain installation directory.
If we compile big-endian 32-bit mips code, crtbegin.o is in the
$TC/lib/gcc/mips-linux-gnu/4.7.2 folder and the toolchain's linker requires
--sysroot=$TC/mips-linux-gnu/libc argument. If we compile little-endian
32-bit soft-float mips code, crtbegin.o is in the
$TC/lib/gcc/mips-linux-gnu/4.7.2/soft-float/el folder and the toolchain's
linker requires --sysroot=$TC/mips-linux-gnu/libc/soft-float/el argument.

1. Calculate MultiarchSuffix using all necessary command line options and
   use this MultiarchSuffix to detect crtbegin.o location in the
   GCCInstallationDetector::ScanLibDirForGCCTriple() routine.
2. If a user does not provide --sysroot argument to the driver explicitly,
   calculate new sysroot value based on command line options. Then use this
   calculated sysroot path:
   a. To populate a file search paths list in the Linux::Linux() constructor.
   b. To find Mips toolchain specific include headers directories
      in the Linux::AddClangSystemIncludeArgs() routine.
   c. To provide -–sysroot argument for a linker.

Note:
- The FSF's tree slightly differs (folder names) and is not supported
  yet.
- New addExternCSystemIncludeIfExits() routine is a temporary solution.
  I plan to move path existence check to the addExternCSystemInclude()
  routine by a separate commit.

The patch reviewed by Rafael Espindola.
http://llvm-reviews.chandlerc.com/D644

llvm-svn: 179934

SLPVectorizer: Reduce the compile time by eliminating the search for some of the more expensive patterns. After this change will only check basic arithmetic trees that start at cmpinstr.

llvm-svn: 179933

llvm-svn: 179932

llvm-svn: 179931

llvm-svn: 179930

llvm-svn: 179929

llvm-svn: 179928

llvm-svn: 179927