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

There were two problems with the initial fix.

1. The added tests flushed out that we misconfigured _LIBCPP_EXPLICIT with GCC.

2. Because the boolean type was a member function template it caused weird link
   errors. I'm assuming due to the vague linkage rules. This time the bool type
   is a non-template member function pointer. That seems to have fixed the
   failing tests. Plus it will end up generating less symbols overall, since
   the bool type is no longer per instantiation.

original commit message below
-----------------------------

std::basic_ios has an operator bool(). In C++11 and later
it is explicit, and only allows contextual implicit conversions.

However explicit isn't available in C++03 which causes std::istream (et al)
to have an implicit conversion to int. This can easily cause ambiguities
when calling operator<< and operator>>.

This patch uses a "bool-like" type in C++03 to work around this. The
"bool-like" type is an arbitrary pointer to member function type. It
will not convert to either int or void*, but will convert to bool.

llvm-svn: 290754

llvm-svn: 290753

llvm-svn: 290752

llvm-svn: 290751

std::basic_ios has an operator bool(). In C++11 and later
it is explicit, and only allows contextual implicit conversions.

However explicit isn't available in C++03 which causes std::istream (et al)
to have an implicit conversion to int. This can easily cause ambiguities
when calling operator<< and operator>>.

This patch uses a "bool-like" type in C++03 to work around this. The
"bool-like" type is an arbitrary pointer to member function type. It
will not convert to either int or void*, but will convert to bool.

llvm-svn: 290750

[ADT] Fix for compilation error when operator++(int) (post-increment function) of SmallPtrSetIterator is used.
The bug was introduced in r289619.

Reviewers: Mehdi Amini

Subscribers: llvm-commits

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

llvm-svn: 290749

Back in r240527 I added a knob to prevent thread-unsafe functions from
being exposed. mblen(), mbtowc() and wctomb() were also added to this
list, as the latest issue of POSIX doesn't require these functions to be
thread-safe.

It turns out that the only circumstance in which these functions are not
thread-safe is in case they are used in combination with state-dependent
character sets (e.g., Shift-JIS). According to Austin Group Bug 708,
these character sets "[...] are mostly a relic of the past and which
were never supported on most POSIX systems".

Though in many cases the use of these functions can be prevented by
using the reentrant counterparts, they are the only functions that allow
you to query whether the locale's character set is state-dependent. This
means that omitting these functions removes actual functionality.

Let's be a bit less pedantic and drop the guards around these functions.

Links:
http://austingroupbugs.net/view.php?id=708
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2037.htm

Reviewed by:	ericwf
Differential Revision:	https://reviews.llvm.org/D21436

llvm-svn: 290748

I have a created a new check for clang tidy: misc-string-compare. This will check for incorrect usage of std::string::compare when used to check equality or inequality of string instead of the string equality or inequality operators.

Example:
```
  std::string str1, str2;
  if (str1.compare(str2)) {
  }
```

Reviewers: hokein, aaron.ballman, alexfh, malcolm.parsons

Subscribers: xazax.hun, Eugene.Zelenko, cfe-commits, malcolm.parsons, Prazek, mgorny, JDevlieghere

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

llvm-svn: 290747

llvm-svn: 290746

llvm-svn: 290745

This implements the compiler side of p0403r0. This patch was reviewed as
https://reviews.llvm.org/D26829.

llvm-svn: 290744

llvm-svn: 290743

llvm-svn: 290742

llvm-svn: 290741

I remove one extra line, but because annoyingly llvm-lit does not
clean the output directory before running the test, it didn't fail
locally (the file was present from a previous run).

llvm-svn: 290740

llvm-svn: 290739