In my build environment (cmake 3.6.1 and gcc 4.8.5 on CentOS 7), having
an empty CMAKE_SYSROOT in the cache results in --sysroot="" being passed
to all compile commands, and then the compiler errors out because of the
empty sysroot. Only set CMAKE_SYSROOT if non-empty to avoid this.

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

llvm-svn: 320183

These should be the only remaining missing install-*-stripped targets.
They're modeled after the existing install targets.

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

llvm-svn: 320182

llvm-svn: 320181

Causes unexpected memory issue with New PM this time.
The new PM invalidates BPI but not BFI, leaving the
reference to BPI from BFI invalid.

Abandon this patch.  There is a more general solution
which also handles runtime infinite loop (but not statically).

llvm-svn: 320180

llvm-svn: 320179

This flag can be ignored because we always emit long PLTs.

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

llvm-svn: 320178

Currently tagged these as system instructions.

llvm-svn: 320177

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

llvm-svn: 320176

llvm-svn: 320175

llvm-svn: 320174

Currently tagged these as system instructions, once we have uses for them (ASAN?) and they are faster we will need to improve on this.

llvm-svn: 320173

Add test for weakly defined symbols with the same name

Improve test for call-indirect to include the same call in two
different objects. This lays the ground work to improve the
output via de-duplicating the indirect call table:
   https://reviews.llvm.org/D40989

Also make all tests consistently pass -mtriple rather than
declaring in the sources.

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

llvm-svn: 320172

These are aliases, but the thing we're checking here is that the target has
vpsllv*, not that the data type is 256-bit. Those instructions exist for
128-bit vectors too...but sadly, not for all element sizes.

llvm-svn: 320170

llvm-svn: 320169

llvm-svn: 320168

This adds a `--no-entry` argument to wasm LLD used to
suppress the default `_start` entry point.

Patch by Nicholas Wilson!

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

llvm-svn: 320167

Summary:
llvm-objdump's Mach-O parser was updated in r306037 to display external
relocations for MH_KEXT_BUNDLE file types. This change extends the Macho-O
parser to display local relocations for MH_PRELOAD files. When used with
the -macho option relocations will be displayed in a historical format.

rdar://35778019

Reviewers: enderby

Reviewed By: enderby

Subscribers: llvm-commits

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

llvm-svn: 320166

The -ldl library is missing on NetBSD too, make the comment more generic.

llvm-svn: 320165

We work around the fact that some platforms add a triple when
they expand llc_dwarf in lit.

llvm-svn: 320164

This supports using a newer libunwind with an older installation of LLVM
(whose cmake modules wouldn't have add_llvm_install_targets).

llvm-svn: 320163

> Unify implementation of our two different flavours of -Wtautological-compare.
>
> In so doing, fix a handful of remaining bugs where we would report false
> positives or false negatives if we promote a signed value to an unsigned type
> for the comparison.

This caused a new warning in Chromium:

../../base/trace_event/trace_log.cc:1545:29: error: comparison of constant 64
with expression of type 'unsigned int' is always true
[-Werror,-Wtautological-constant-out-of-range-compare]
  DCHECK(handle.event_index < TraceBufferChunk::kTraceBufferChunkSize);
         ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The 'unsigned int' is really a 6-bit bitfield, which is why it's always
less than 64.

I thought we didn't use to warn (with out-of-range-compare) when comparing
against the boundaries of a type?

llvm-svn: 320162

Put these under VecIMul itinerary classes for now - seems to be a good average value

llvm-svn: 320161

Summary:
It looks like clang was generating somewhat weird assembly with the current
code. `FromPrimary`, even though `const`,  was replaced every time with the code
generated for `size <= SizeClassMap::kMaxSize` instead of using a variable or
register, and `FromPrimary` didn't induce `ClassId != 0` for the compiler, so a
dead branch was generated for `getActuallyAllocatedSize(Ptr, ClassId)` since
it's never called for `ClassId = 0` (Secondary backed allocations) [this one
was more wishful thinking on my side than anything else].

I rearranged the code bit so that the generated assembly is less clunky.

Also changed 2 whitespace inconsistencies that were bothering me.

Reviewers: alekseyshl, flowerhack

Reviewed By: flowerhack

Subscribers: llvm-commits, #sanitizers

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

llvm-svn: 320160

llvm-svn: 320159

llvm-svn: 320158

[InstCombine] PR35354: Convert store(bitcast, load bitcast (select (Cond, &V1, &V2))  --> store (, load (select(Cond, load &V1, load &V2)))

Summary:
If we have the code like this:
```
float a, b;
a = std::max(a ,b);
```
it is converted into something like this:
```
%call = call dereferenceable(4) float* @_ZSt3maxIfERKT_S2_S2_(float* nonnull dereferenceable(4) %a.addr, float* nonnull dereferenceable(4) %b.addr)
%1 = bitcast float* %call to i32*
%2 = load i32, i32* %1, align 4
%3 = bitcast float* %a.addr to i32*
store i32 %2, i32* %3, align 4
```
After inlinning this code is converted to the next:
```
%1 = load float, float* %a.addr
%2 = load float, float* %b.addr
%cmp.i = fcmp fast olt float %1, %2
%__b.__a.i = select i1 %cmp.i, float* %a.addr, float* %b.addr
%3 = bitcast float* %__b.__a.i to i32*
%4 = load i32, i32* %3, align 4
%5 = bitcast float* %arrayidx to i32*
store i32 %4, i32* %5, align 4

```
This pattern is not recognized as minmax pattern.
Patch solves this problem by converting sequence
```
store (bitcast, (load bitcast (select ((cmp V1, V2), &V1, &V2))))
```
to a sequence
```
store (,load (select((cmp V1, V2), &V1, &V2)))
```
After this the code is recognized as minmax pattern.

Reviewers: RKSimon, spatel

Subscribers: llvm-commits

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

llvm-svn: 320157

llvm-svn: 320156

llvm-svn: 320155

Match VPTERNLOG which these pseudos will eventually alias to

llvm-svn: 320154

The bots have been updated, this option isn't needed anymore.

llvm-svn: 320153

All architectures except x86_64 used the linear barrier implementation
by default which doesn't give good performance for a larger number
of threads.

Improvements for PARALLEL overhead (EPCC) with this patch on a Power8
system (2 sockets x 10 cores x 8 threads, OMP_PLACES=cores)

 20 threads:  4.55us -> 3.49us
 40 threads:  8.84us -> 4.06us
 80 threads: 19.18us -> 4.74us
160 threads: 54.22us -> 6.73us

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

llvm-svn: 320152

To make thread affinity work according to the OpenMP spec, the
runtime needs information about the hardware topology. On Linux
the default way is to parse /proc/cpuinfo which contains this
information for x86 machines but (at least) not for AArch64 and
Power architectures.

Fortunately, there is a different code path which is able to get
that data from sysfs. The needed patch has landed in 2006 for
Linux 2.6.16 which is safe to assume nowadays (even RHEL 5 had
a kernel version derived from 2.6.18, and we are now at RHEL 7!).

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

llvm-svn: 320151

Otherwise I see hangs in the omp_single_copyprivate test when
compiling in release mode. With the debug assertions, I get a
failure `head > 0 && tail > 0`.

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

llvm-svn: 320150

Host + default devices codegen for `target teams distribute` directive.

llvm-svn: 320149

Summary: This improves readability of tests and error messages.

Reviewers: ioeric

Subscribers: klimek, ilya-biryukov, cfe-commits

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

llvm-svn: 320148

Reviewers: ruiu, grimar

Reviewed By: ruiu

Subscribers: emaste, javed.absar, llvm-commits

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

llvm-svn: 320147

Summary:
+DumpCode is a hack to embed disassembly in the ELF file. This commit
fixes it to include labels, to make it slightly more useful.

Reviewers: arsenm, kzhuravl

Subscribers: nhaehnle, timcorringham, dstuttard, llvm-commits, t-tye, yaxunl, wdng, kzhuravl

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

llvm-svn: 320146

llvm-svn: 320144

In this method, we invoke `SimplifyICmpOperands` which takes the `Cond` predicate
by reference and may change it along with `LHS` and `RHS` SCEVs. But then we invoke
`computeShiftCompareExitLimit` with Values from which the SCEVs have been derived,
these Values have not been modified while `Cond` could be.

One of possible outcomes of this is that we may falsely prove that an infinite loop ends
within some finite number of iterations.

In this patch, we save the original `Cond` and pass it along with original operands.
This logic may be removed in future once `computeShiftCompareExitLimit` works
with SCEVs instead of value operands.

Reviewed By: sanjoy
Differential Revision: https://reviews.llvm.org/D40953

llvm-svn: 320142

Work towards the unification of MIR and debug output by refactoring the
interfaces.

llvm-svn: 320141