These are tests for store transforms. 
The loads, adds, and geps were irrelevant.

llvm-svn: 264526

The prior diagnostic (err_template_arg_not_class_template) would state that the template argument to a template template parameter can only be a class template, when it can also be a template alias.  The newly renamed diagnostic (err_template_arg_not_valid_template) mentions template aliases.

llvm-svn: 264522

llvm-svn: 264521

If you're building dwps from other dwps, it can be hard to track down a
duplicate CU ID if it comes from two compilations of the same file in
different modes, etc. By including the .dwo path (which is hopefully
more unique than the file path) it can help track down where the
duplicates came from.

llvm-svn: 264520

The FileSystem::makeAbsolute function has been calculating the current
working directory unconditionally, even when it is not needed. This calls
down to llvm::sys::fs::current_path, which is relatively expensive
because it stats two directories, regardless of whether those paths are
already in the stat cache. The net effect is that when using the
VFS, every stat during header search turns into three stats. With this
change, we get back to a single stat for absolute directory paths.

llvm-svn: 264519

Suggested by: Rui Ueyama.

llvm-svn: 264518

Correct splitting of v8i32 vectors into v4i32 vectors to prevent scalarization

llvm-svn: 264517

This reverts commit fa36fcff16c7d4f78204d6296bf96c3558a4a672.

Causes the following Windows failure:

  C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\lib\CodeGen\MachineInstr.cpp(762):
  error C2338: must be trivially copyable to memmove

llvm-svn: 264516

Summary: isPodLike is as close as we have for is_trivially_copyable.

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D18483

llvm-svn: 264515

  This patch applies the restrictions on the number of domain conjuncts
  also to the domain parts of piecewise affine expressions we generate.
  To this end the wording is change slightly. It was needed to support
  complex additions featuring zext-instructions but it also fixes PR27045.

  lnt profitable runs reports only little changes that might be noise:
  Compile Time:
    Polybench/[...]/2mm                     +4.34%
    SingleSource/[...]/stepanov_container   -2.43%
  Execution Time:
    External/[...]/186_crafty               -2.32%
    External/[...]/188_ammp                 -1.89%
    External/[...]/473_astar                -1.87%

llvm-svn: 264514

[Cxx1z-constexpr-lambda-P0170R1]  Support parsing of constexpr specifier (and its inference) on lambda expressions

Support the constexpr specifier on lambda expressions - and support its inference from the lambda call operator's body.

i.e.
  auto L = [] () constexpr { return 5; };
  static_assert(L() == 5); // OK
  auto Implicit = [] (auto a) { return a; };
  static_assert(Implicit(5) == 5); 

We do not support evaluation of lambda's within constant expressions just yet.

Implementation Strategy:
  - teach ParseLambdaExpressionAfterIntroducer to expect a constexpr specifier and mark the invented function call operator's declarator's decl-specifier with it; Have it emit fixits for multiple decl-specifiers (mutable or constexpr) in this location.
  - for cases where constexpr is not explicitly specified, have buildLambdaExpr check whether the invented function call operator satisfies the requirements of a constexpr function, by calling CheckConstexprFunctionDecl/Body.

Much obliged to Richard Smith for his patience and his care, in ensuring the code is clang-worthy.

llvm-svn: 264513

Correct splitting of v16i16 vectors into v8i16 vectors to prevent scalarization

Differential Revision: http://reviews.llvm.org/D18307

llvm-svn: 264512

Currently this is to mainly to prevent scalarization of integer division by constants.

Differential Revision: http://reviews.llvm.org/D18307

llvm-svn: 264511

llvm-svn: 264510

Only pre-AVX512BW targets need to split v32i8 vectors.

llvm-svn: 264509

The minnum and maxnum intrinsics get lowered to libcalls which
invalidates the CTR optimization.

This fixes PR27083.

llvm-svn: 264508

Add all 256-bit vector tests.
Added AVX512F/AVX512BW test targets.
Renamed tests something more meaningful.

llvm-svn: 264507

LowerMul v32i8 on AVX2 needs to split the 256-bit sources to allow sign-extension back to v16i16 to occur. Since this is basically the same as Lower256IntArith we simplify by using that here instead.

llvm-svn: 264506

llvm-svn: 264505

[Power9] Implement new altivec instructions: permute, count zero, extend sign, negate, parity, shift/rotate, mul10

This change implements the following vector operations:
- vclzlsbb vctzlsbb vctzb vctzd vctzh vctzw
- vextsb2w vextsh2w vextsb2d vextsh2d vextsw2d
- vnegd vnegw
- vprtybd vprtybq vprtybw
- vbpermd vpermr
- vrlwnm vrlwmi vrldnm vrldmi vslv vsrv
- vmul10cuq vmul10uq vmul10ecuq vmul10euq

28 instructions

Thanks Nemanja, Kit for invaluable hints and discussion!
Reviewers: hal, nemanja, kbarton, tjablin, amehsan

Phabricator: http://reviews.llvm.org/D15887
llvm-svn: 264504

Summary:
Now that the summary contains the full reference/call graph, we can
replace the existing function importer that loads and inspect the IR
to iteratively walk the call graph by a traversal based purely on the
summary information. Decouple the actual importing decision from any
IR manipulation.

Reviewers: tejohnson

Subscribers: llvm-commits, joker.eph

Differential Revision: http://reviews.llvm.org/D18343

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264503

llvm-svn: 264502

On PS4, we have to fake environment variables by passing extra command
line arguments, so the dummy test `argc > 1` was failing.
The condition is just a dummy condition that the compiler can't fold
away, so the number is arbitrary as long as the condition is false.

Increase the number it compares against.

llvm-svn: 264491

llvm-svn: 264490

It now return the map instead of an iterator.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264489

llvm-svn: 264488

llvm-svn: 264487

preposterously large for some lookup tables -- in C++ classes generated by
template instantiation, it's very common for the number of lookup results to be
either 1 or 2.

This reduces size of a libstdc++ module by 7-15%.

llvm-svn: 264486

The ASTImporter completes the full definiton for a TagDecl in several places,
including the type-deport logic.  When this happens, we should also propagate
the bit that says that this is a complete definition.  This makes (for example)
lambdas callable.

<rdar://problem/22864976>

llvm-svn: 264485

Simply searching for gooddir/* and baddir/* instead of *.s the script
should also work with .o files.

llvm-svn: 264484

Blocks and lambdas have their implementation functions stored in the IR for an
expression.  If we put the block/lambda into a result variable it needs to stay
around.  As a heuristic, remember any execution unit that has more than one
function in it.

<rdar://problem/22864976>

llvm-svn: 264483

See http://lists.llvm.org/pipermail/llvm-dev/2016-March/097640.html
There is also a description/tutorial in the comments of the abtest.py
file.

llvm-svn: 264482

[asan] bump the scariness score of read-after-frees (based on feedback from the Chrome security team)

llvm-svn: 264481

Differential Revision: http://reviews.llvm.org/D18485

llvm-svn: 264480

As discussed on the llvm-commits thread for r264467.

llvm-svn: 264479

llvm-svn: 264478

the rename operation on 3 error conditions of ReplaceFileW() that it was 
previously bailing out on.

Patch by Douglas Yung!

Differential Revision: http://reviews.llvm.org/D17903

llvm-svn: 264477

Summary:
This fixes a leak introduced by some of these changes:
r257644
r250530
r250525

The changes made in these patches result in leaking the FILE* passed
to SetImmediateOutputFile. GetStream() will dup() the fd held by the
python caller and create a new FILE*. It will then pass this FILE*
to SetImmediateOutputFile, which always uses the flag
transfer_ownership=false when it creates a File from the FILE*.

Since transfer_ownership is false, the lldb File destructor will not
close the underlying FILE*. Because this FILE* came from a dup-ed fd,
it will also not be closed when the python caller closes its file.

Leaking the FILE* causes issues if the same file is used multiple times
by different python callers during the same lldb run, even if these
callers open and close the python file properly, as you can end up
with issues due to multiple buffered writes to the same file.

Reviewers: granata.enrico, zturner, clayborg

Subscribers: zturner, lldb-commits, sas

Differential Revision: http://reviews.llvm.org/D18459

Change by Francis Ricci <fjricci@fb.com>

llvm-svn: 264476

This makes us no longer relying on move-construction elision by the compiler.
Suggested by D. Blaikie.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264475

Add a 'language cplusplus demangle' command. This can be useful to provide a low-friction reproduction for issues with the LLDB demangling of C++ symbols

llvm-svn: 264474