This is useful for e.g. highlighting purposes in an IDE.

Patch by Nikolai Kosjar.

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

llvm-svn: 321697

As experimental backends, I didn't have them configured to build in my local 
build config.

llvm-svn: 321696

This is the follow up patch for rL319881 which introduced
the function but did not put it into .exports file.

llvm-svn: 321695

TargetRegistryInfo::createMCAsmBackend no longer takes a TheTriple parameter. 
The majory of the TargetRegistryInfo::create* functions have no or very 
limitied per-parameter doc comments, and adding a comment for the 
MCSubtargetInfo, MCRegisterInfo and MCTargetOptions parameters seems like it 
would add no real value beyond reading the function signature. As such, I've 
just deleted the doc comment for TheTriple.

llvm-svn: 321694

llvm-svn: 321693

Currently it's not possible to access MCSubtargetInfo from a TgtMCAsmBackend. 
D20830 threaded an MCSubtargetInfo reference through 
MCAsmBackend::relaxInstruction, but this isn't the only function that would 
benefit from access. This patch removes the Triple and CPUString arguments 
from createMCAsmBackend and replaces them with MCSubtargetInfo.

This patch just changes the interface without making any intentional 
functional changes. Once in, several cleanups are possible:
* Get rid of the awkward MCSubtargetInfo handling in ARMAsmBackend
* Support 16-bit instructions when valid in MipsAsmBackend::writeNopData
* Get rid of the CPU string parsing in X86AsmBackend and just use a SubtargetFeature for HasNopl
* Emit 16-bit nops in RISCVAsmBackend::writeNopData if the compressed instruction set extension is enabled (see D41221)

This change initially exposed PR35686, which has since been resolved in r321026.

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

llvm-svn: 321692

Summary:
The diagnostic was mostly introduced in D38101 by me, as a reaction to wasting a lot of time, see [[ https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171009/206427.html | mail ]].
However, the diagnostic is pretty dumb. While it works with no false-positives,
there are some questionable cases that are diagnosed when one would argue that they should not be.

The common complaint is that it diagnoses the comparisons between an `int` and
`long` when compiling for a 32-bit target as tautological, but not when
compiling for 64-bit targets. The underlying problem is obvious: data model.
In most cases, 64-bit target is `LP64` (`int` is 32-bit, `long` and pointer are
64-bit), and the 32-bit target is `ILP32` (`int`, `long`, and pointer are 32-bit).

I.e. the common pattern is: (pseudocode)
```
#include <limits>
#include <cstdint>
int main() {
  using T1 = long;
  using T2 = int;

  T1 r;
  if (r < std::numeric_limits<T2>::min()) {}
  if (r > std::numeric_limits<T2>::max()) {}
}
```
As an example, D39149 was trying to fix this diagnostic in libc++, and it was not well-received.

This *could* be "fixed", by changing the diagnostics logic to something like
`if the types of the values being compared are different, but are of the same size, then do diagnose`,
and i even attempted to do so in D39462, but as @rjmccall rightfully commented,
that implementation is incomplete to say the least.

So to stop causing trouble, and avoid contaminating upcoming release, lets do this workaround:
* move these three diags (`warn_unsigned_always_true_comparison`, `warn_unsigned_enum_always_true_comparison`, `warn_tautological_constant_compare`) into it's own `-Wtautological-constant-in-range-compare`
* Disable them by default
* Make them part of `-Wextra`
* Additionally, give `warn_tautological_constant_compare` it's own flag `-Wtautological-type-limit-compare`.
  I'm not happy about that name, but i can't come up with anything better.

This way all three of them can be enabled/disabled either altogether, or one-by-one.

Reviewers: aaron.ballman, rsmith, smeenai, rjmccall, rnk, mclow.lists, dim

Reviewed By: aaron.ballman, rsmith, dim

Subscribers: thakis, compnerd, mehdi_amini, dim, hans, cfe-commits, rjmccall

Tags: #clang

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

llvm-svn: 321691

Previously the code for handling G_SMULO didn't properly check for the signed
multiply overflow, instead treating it the same as the unsigned G_UMULO.

Fixes PR35800.

llvm-svn: 321690

llvm-svn: 321689

llvm-svn: 321688

llvm-svn: 321687

variable is extern "C" in linkage calculations.

llvm-svn: 321686

llvm-svn: 321685

If a section is RW there is no reason to drop a relocation with a weak
undefined symbol.

llvm-svn: 321684

Fix and simplify handling of return type for (generic) lambda conversion function to function pointer.

Previously, we would:
 * compute the type of the conversion function and static invoker as a
   side-effect of template argument deduction for a conversion
 * re-compute the type as part of deduced return type deduction when building
   the conversion function itself

Neither of these turns out to be quite correct. There are other ways to reach a
declaration of the conversion function than in a conversion (such as an
explicit call or friend declaration), and performing auto deduction causes the
function type to be rebuilt in the context of the lambda closure type (which is
different from the context in which it originally appeared, resulting in
spurious substitution failures for constructs that are valid in one context but
not the other, such as the use of an enclosing class's "this" pointer).

This patch switches us to use a different strategy: as before, we use the
declared type of the operator() to form the type of the conversion function and
invoker, but we now populate that type as part of return type deduction for the
conversion function. And the invoker is now treated as simply being an
implementation detail of building the conversion function, and isn't given
special treatment by template argument deduction for the conversion function
any more.

llvm-svn: 321683

This addresses an issue introduced in r183451: since
`removePiecesWithInvalidLocations` is called *after* `adjustCallLocations`,
it is not necessary, and in fact harmful, to have this assertion in
adjustCallLocations.

Addresses rdar://36170689

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

llvm-svn: 321682

I have no clue how this was missed when symbol table support was added. This
change ensures that the visibility of symbols is preserved by default.

llvm-svn: 321681

Initial working version of libunwind for PowerPC 64. Tested on
little-endian ppc64 host only.
Based on the existing PowerPC 32 code.

It supports:

- context save/restore (unw_getcontext, unw_init_local, unw_resume)
- read/write from/to saved registers
- backtrace (unw_step)

Patch by Leandro Lupori!

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

Now builds with LIBUNWIND_ENABLE_CROSS_UNWINDING=ON should
work.

llvm-svn: 321680

For builds that only target one architecture, this was required to
be an exact match, while it previously required the allocation to be
strictly larger than the largest concrete one. Requiring it to be
larger than on equal should be enough.

This makes it more straightforward to update _LIBUNWIND_CONTEXT_SIZE
and _LIBUNWIND_CURSOR_SIZE.

llvm-svn: 321679

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

llvm-svn: 321678

Summary:
This way new asan_device_setup, which knows about the quirks of
recent releases of Android, can be used with older ASan runtime
library (say, from an NDK release). The library is version locked to
the compiler, and is often hard or impossible to update.

Reviewers: vitalybuka

Subscribers: srhines, kubamracek, llvm-commits

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

llvm-svn: 321677

Fixes verifier errors with Windows EH and OpenMP, which injects a
terminate scope around parallel blocks.

Fixes PR35778

llvm-svn: 321676

This patch enables OMPT by default if version 50 or later is built and the config says, that OMPT will be supported.

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

llvm-svn: 321675

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

Change-Id: Ie3a405b28503ceae999f5f3ba07a68fa733a2400
llvm-svn: 321674

llvm-svn: 321673

This is part of solving PR35717:
https://bugs.llvm.org/show_bug.cgi?id=35717

The larger IR optimization is proposed in D41603, but we can show 
the improvement in ValueTracking using codegen tests because 
SelectionDAG creates min/max nodes based on ValueTracking. 

Any target with min/max ops should show wins here. I chose AArch64
vector ops because they're clean and uniform.

Some Alive proofs for the tests (can't put more than 2 tests in 1 
page currently because the web app says it's too long):
https://rise4fun.com/Alive/WRN
https://rise4fun.com/Alive/iPm
https://rise4fun.com/Alive/HmY
https://rise4fun.com/Alive/CNm
https://rise4fun.com/Alive/LYf

llvm-svn: 321672

- Fix formatting issue due to hyphenated terms at line breaks.
- Fix typo

This patch was made by Craig Flores

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

llvm-svn: 321671

- Fix incorrect wording in various intrinsic descriptions. Previously the descriptions used "low-order" and "high-order" when the intended meaning was "even-indexed" and "odd-indexed".

This patch was made by Craig Flores

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

llvm-svn: 321670

- Fixed innaccurate instruction mappings for various intrinsics.
- Fixed description of NaN handling in comparison intrinsics.
- Unify description of _mm_store_pd1 to match _mm_store1_pd.
- Fix incorrect wording in various intrinsic descriptions. Previously the descriptions used "low-order" and "high-order" when the intended meaning was "even-indexed" and "odd-indexed".
- Fix typos.
- Add missing italics command (\a) for params and fixed some parameter spellings.

This patch was made by Craig Flores

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

llvm-svn: 321669

llvm-svn: 321668

Initial working version of libunwind for PowerPC 64. Tested on
little-endian ppc64 host only.
Based on the existing PowerPC 32 code.

It supports:

- context save/restore (unw_getcontext, unw_init_local, unw_resume)
- read/write from/to saved registers
- backtrace (unw_step)

Patch by Leandro Lupori!

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

llvm-svn: 321667

llvm-svn: 321666

The way to fix an undefined-template warning is to add lines to the header file that defines the template pattern. We should suppress the warnings when the template pattern is in a system header because we don't expect users to edit those.

llvm-svn: 321665

llvm-svn: 321664

llvm-svn: 321663

A call may have an intrinsic name but not have a valid intrinsic ID,
for example with llvm.invariant.group.barrier. If so, treat it as a
normal call like FastISel does.

llvm-svn: 321662

llvm-svn: 321661

rdar://problem/33251668

Reviewers: arphaman, ahatanak

Reviewed By: arphaman

Subscribers: ptitei, cfe-commits

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

llvm-svn: 321660

Some systems still don't have this module which was introduced in
version 2.0 (CentOS 7, sigh).

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

llvm-svn: 321659

Implement most of P0607: Inline Variables for the Standard Library. This involved marking a lot of variables as inline (but only for C++17 and later).

llvm-svn: 321658