I'm not sure if this was intentional, but today
isGuaranteedToTransferExecutionToSuccessor returns true for readonly and
argmemonly calls that may throw.  This commit changes the function to
not implicitly infer nounwind this way.

Even if we eventually specify readonly calls as not throwing,
isGuaranteedToTransferExecutionToSuccessor is not the best place to
infer that.  We should instead teach FunctionAttrs or some other such
pass to tag readonly functions / calls as nounwind instead.

llvm-svn: 290794

llvm-svn: 290793

to be specified for a template template parameter whenever the parameter is at
least as specialized as the argument (when there's an obvious and correct
mapping from uses of the parameter to uses of the argument). For example, a
template with more parameters can be passed to a template template parameter
with fewer, if those trailing parameters have default arguments.

This is disabled by default, despite being a DR resolution, as it's fairly
broken in its current state: there are no partial ordering rules to cope with
template template parameters that have different parameter lists, meaning that
code that attempts to decompose template-ids based on arity can hit unavoidable
ambiguity issues.

The diagnostics produced on a non-matching argument are also pretty bad right
now, but I aim to improve them in a subsequent commit.

llvm-svn: 290792

When building libc++ without threading, strerror_r is not used.  Define
the code only when threading is enabled.  This allows us to build
system_error for Windows, which ATM doesn't build with threading.

llvm-svn: 290791

llvm-svn: 290790

This cleans up the `-Wqual-cast` warnings from gcc 6 when building
libc++.  NFC.

llvm-svn: 290789

Clean up the misleading indentation warning from GCC 6.  NFC

llvm-svn: 290788

We bail out on the 1st line if the assumption cache is not set, so there's
no need to check it after that.

llvm-svn: 290787

[ValueTracking] make dominator tree requirement explicit for isKnownNonNullFromDominatingCondition(); NFCI

I don't think this hole is currently exposed, but I crashed regression tests for
jump-threading and loop-vectorize after I added calls to isKnownNonNullAt() in
InstSimplify as part of trying to solve PR28430:
https://llvm.org/bugs/show_bug.cgi?id=28430

That's because they call into value tracking with a context instruction, but no
other parts of the query structure filled in.

For more background, see the discussion in:
https://reviews.llvm.org/D27855

llvm-svn: 290786

These exception types are marked with `_LIBCPP_EXCEPTION_ABI` which
expands to `__attribute__((__visibility__("default")))` or
`__declspec(dllexport)`.  When building for Windows, we would hit an
error:

    cannot apply 'dllexport' to a 'dllexport' class

Remove the duplicate annotations as they will be inherited from the
class.

llvm-svn: 290785

This check detects and fixes redundant null checks before deletes.

Patch by: Gergely Angeli!

Differential Revision: https://reviews.llvm.org/D21298

llvm-svn: 290784

Even more isl coalesce changes.

llvm-svn: 290783

llvm-svn: 290782

This diff fixes the clean build of the target generate-order-file.
In llvm/tools/clang/CMakeLists.txt 
add_subdirectory(utils/perf-training) should go after the block where 
the value of the variable CLANG_ORDER_FILE is set - otherwise 
(tested with cmake's version 3.6.2) the arguments of perf-helper.py gen-order-file
will be ill-formed (CLANG_ORDER_FILE will be empty).

Differential revision: https://reviews.llvm.org/D28153

llvm-svn: 290781

llvm-svn: 290780

This was originally motivated by a compile time problem I've since figured out how to solve differently, but the cleanup seemed useful. We had the same logic - which essentially implemented find - in several places. By commoning them out, I can implement find and allow erase to be inlined at the call sites if profitable.

Differential Revision: https://reviews.llvm.org/D28183

llvm-svn: 290779

Summary: Fixes PR 31345

Reviewers: dylanmckay

Subscribers: fhahn, llvm-commits

Differential Revision: https://reviews.llvm.org/D28186

llvm-svn: 290778

llvm-svn: 290777

[InstCombine][AVX-512] Teach InstCombine that llvm.x86.avx512.vcomi.sd and llvm.x86.avx512.vcomi.ss don't use the upper elements of their input.

This was already done for the SSE/SSE2 version of the intrinsics.

llvm-svn: 290776

We need to include __config to ensure that we know what random
implementation is being used.  Fixes compilation for Windows.

llvm-svn: 290775

[InstCombine][AVX-512] When turning intrinsics with masking into native IR, don't emit a select if the mask is known to be all ones.

This saves InstCombine the burden of having to optimize the select later.

llvm-svn: 290774

llvm-svn: 290773

llvm-svn: 290772

Inconsistent naming convention and wrong name for some input/output types.

llvm-svn: 290771

llvm-svn: 290770

llvm-svn: 290769

Minor compile time win.  Avoids an additional O(N) scan in the case where we are removing an element and costs nothing when we aren't.

llvm-svn: 290768

Summary: Update the Phabricator docs to clarify how changes are merged for contributors without commit access. 

Reviewers: delcypher, aaron.ballman

Subscribers: aaron.ballman, anmol, llvm-commits

Differential Revision: https://reviews.llvm.org/D28184

llvm-svn: 290767

There was a small error in the code in the tutorial. The tutorial contains a few errors which results in code not being able to compile.

One error was described here: https://llvm.org/bugs/show_bug.cgi?id=25583 .

I found and fixed the error and one additional error.

Reviewers: aaron.ballman, malcolm.parsons

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D28180

llvm-svn: 290766

Since we type-erase the Windows GUID structure, use unsigned bytes
rather than char, which may be signed (-fsigned-char).  NFC

llvm-svn: 290765

Assert that the size of the MD5 result is the same size as the signature
field being populated.  Use the sizeof operator to determine the size of
the field being written rather than hardcoding it to the magic number
16.  NFC.

llvm-svn: 290764

Summary:
gep 0, 0 is equivalent to bitcast. LLVM canonicalizes it
to getelementptr because it make SROA can then handle it.

Simple case like

    void g(A &a) {
        z(a);
        if (glob)
            a.foo();
    }
    void testG() {
        A a;
        g(a);
    }

was not devirtualized with -fstrict-vtable-pointers because luck of
handling for gep 0 in Memory Dependence Analysis

Reviewers: dberlin, nlewycky, chandlerc

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D28126

llvm-svn: 290763

Change the cascading ifs to a StringSwitch to simplify the conversion of
the relocation model.  NFC

llvm-svn: 290762

string::find used to call the generic algorithm ::find.  The patch special
case string::find such that it ultimately gets converted to calls to memchr
and memcmp.

The patch improves the performance of the string::find routine by about 20x.

Without the patch, the performance on an x86_64-linux 3400 MHz machine is:

Benchmark                           Time           CPU Iterations
-----------------------------------------------------------------
BM_StringFindNoMatch/10             4 ns          4 ns  166421326
BM_StringFindNoMatch/64            37 ns         37 ns   18754392
BM_StringFindNoMatch/512          268 ns        268 ns    2586060
BM_StringFindNoMatch/4k          2143 ns       2144 ns     328342
BM_StringFindNoMatch/32k        16910 ns      16917 ns      40623
BM_StringFindNoMatch/128k       67577 ns      67602 ns      10138
BM_StringFindAllMatch/1             3 ns          3 ns  265163471
BM_StringFindAllMatch/8             6 ns          6 ns  112582467
BM_Str...

CVP doesn't care about the order of blocks visited, but by using a pre-order traversal over the graph we can a) not visit unreachable blocks and b) optimize as we go so that analysis of later blocks produce slightly more precise results.

I noticed this via inspection and don't have a concrete example which points to the issue.  

llvm-svn: 290760

Minor compile time win.  Not known to be a hot spot, just something I noticed while reading.

llvm-svn: 290759

llvm-svn: 290758

Caught a simple typo. I do not know of a way to test this, but it seems like an unlikely thing to regress in the future.

llvm-svn: 290757

llvm-svn: 290756

llvm-svn: 290755