Continuing the work from last week to remove implicit ilist iterator
conversions.  First related commit was probably r249767, with some more
motivation in r249925.  This edition gets LLVMTransformUtils compiling
without the implicit conversions.

No functional change intended.

llvm-svn: 250142

on some of the bots.  I’ll remove this test for now.

llvm-svn: 250141

say which module file referenced the missing file.

llvm-svn: 250140

Now that the base class is templated, it is redundant with the type.

llvm-svn: 250139

The comment says this was stopped because it was unlikely to be
profitable. This is not true if you want to combine vector loads
with multiple components.

For a simple case that looks like

t0 = load t0 ...
t1 = load t0 ...
t2 = load t0 ...
t3 = load t0 ...

t4 = store t0:1, t0:1
  t5 = store t4, t1:0
    t6 = store t5, t2:0
	  t7 = store t6, t3:0

We want to get all of these stores onto a chain
that is a TokenFactor of these N loads. This mostly
solves the AMDGPU merge-stores.ll regressions
with -combiner-alias-analysis for merging vector
stores of vector loads.

llvm-svn: 250138

context (but otherwise at the top level) to be disabled, to support use of C++
standard library implementations that (legitimately) mark their <blah.h>
headers as being C++ headers from C libraries that wrap things in 'extern "C"'
a bit too enthusiastically.

llvm-svn: 250137

  !1 = !DIFile(filename: "/var/empty\5C<stdin>", directory: "E:\5Cllvm\5Cbuild\5Ccmake-ninja\5Ctools\5Cclang\5Ctest\5CCodeGen")

llvm-svn: 250136

Summary:
D4796 taught LLVM to fold some atomic integer operations into a single
instruction. The pattern was unaware that the instructions clobbered
flags.

This patch adds the missing EFLAGS definition.

Floating point operations don't set flags, the subsequent fadd
optimization is therefore correct. The same applies for surrounding
load/store optimizations.

Reviewers: rsmith, rtrieu

Subscribers: llvm-commits, reames, morisset

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

llvm-svn: 250135

We model predefined declarations as not being from AST files, but in most ways
they act as if they come from some implicit prebuilt module file imported
before all others. Therefore, if we see an update to the predefined 'struct
__va_list_tag' declaration (and we've already loaded any modules), it needs a
corresponding update record, even though it didn't technically come from an AST
file.

llvm-svn: 250134

llvm-svn: 250133

It should now correctly handle physical registers and make
it easier to identify the other direction.

llvm-svn: 250132

Reviewers: granata.enrico

Subscribers: lldb-commits

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

llvm-svn: 250131

restore the malformed-machos 00000031.a test.  Hopefully this will get all the
build bots happy again.  I’ll again keep an eye on them.

llvm-svn: 250130

This basic combine was surprisingly missing.
AMDGPU legalizes many operations in terms of 32-bit vector components,
so not doing this results in many extra copies and subregister extracts
that need to be cleaned up later.

InstCombine already does this for the hasOneUse case. The target hook
is to fix a handful of tests which break (e.g. ARM/vmov.ll) which turn
from a vector materialize repeated immediate instruction to a constant
vector load with more scalar copies from it.

llvm-svn: 250129

Safestack runtime should never be linked on Android targets because
it is implemented directly in libc. This is already the case, but
mostly by chance (collectSanitizerRuntimes would only link shared
sanitizer runtimes, and safestack has only a static one). Protect
this behavior with a test.

llvm-svn: 250128

llvm-svn: 250127

llvm-svn: 250126

llvm-svn: 250125

This can be used to annotate copies of memory that are not observed by MSan.

llvm-svn: 250124

Under PPC64 ELF v1 ABI, the symbols associated with each function name don't
point directly to the code in the .text section (or similar), but rather to a
function descriptor structure in a special data section named .opd. The
elements in the .opd structure include a pointer to the actual code, and a the
relevant TOC base value. Both of these are themselves set by relocations.

When we have a local call, we need the relevant relocation to refer directly to
the target code, not to the function-descriptor in the .opd section. Only when
we have a .plt stub do we care about the address of the .opd function
descriptor itself.

So we make a few changes here:

 1. Always write .opd first, so that its relocated data values are available
    for later use when writing the text sections. Record a pointer to the .opd
    structure, and its corresponding buffer.

 2. When processing a relative branch relocation under ppc64, if the
    destination points into the .opd section, read the code pointer out of the
    function descriptor structure and use that instead.

This this, I can link, and run, a dynamically-compiled "hello world"
application on big-Endian PPC64/Linux (ELF v1 ABI) using lld.

llvm-svn: 250122

First stage of bugfix discussed in D13348

llvm-svn: 250121

of the build bots get a different error on that malformed file.

llvm-svn: 250120

When lowering invoke statement, all unwind destinations are directly added as successors of call site block, and the weight of those new edges are not assigned properly. Actually, default weight 16 are used for those edges. This patch calculates the proper edge weights for those edges when collecting all unwind destinations.

Differential revision: http://reviews.llvm.org/D13354

llvm-svn: 250119

We have a number of functions that implement constant folding of vectors (unary and binary ops) in near identical manners (and the differences don't appear to be critical).

This patch introduces a common implementation (SelectionDAG::FoldConstantVectorArithmetic) and calls this in both the unary and binary op cases.

After this initial patch I intend to begin enabling vector constant folding for a wider number of opcodes in SelectionDAG::getNode().

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

llvm-svn: 250118

that caused aborts.  This was because of the characters of the ‘Size’ field in
the archive header did not contain decimal characters.

rdar://22983603

llvm-svn: 250117

Summary:
This check flags all usage of pointer arithmetic, because it could lead
to an
invalid pointer.
Subtraction of two pointers is not flagged by this check.

Pointers should only refer to single objects, and pointer arithmetic is
fragile and easy to get wrong. array_view is a bounds-checked, safe type
for accessing arrays of data.

This rule is part of the "Bounds safety" profile of the C++ Core
Guidelines, see
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-bounds1-dont-use-pointer-arithmetic-use-array_view-instead

Depends on D13313

Subscribers: cfe-commits

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

llvm-svn: 250116

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

llvm-svn: 250115

Summary: Add decayedType and hasDecayedType AST matchers

Reviewers: klimek

Subscribers: klimek, cfe-commits

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

llvm-svn: 250114

Old version of sem_init (GLIBC_2.0) fails to initialize parts of
sem_t that are used in sem_timedwait. This is fixed in GLIBC_2.1,
but since ASan interceptors downgrade sem_* to the oldest available
version, this can introduce bugs that are only present in sanitized
build. Workaround by zero-initializing sem_t in sem_init.

llvm-svn: 250113

This failed on AArch64 due to the type mismatch using int instead of
__builtin_va_list.

llvm-svn: 250112

The test failed on Windows due to use of \ as a path separator rather than /.

llvm-svn: 250111

Under the PPC64 ELF ABI, functions that might call into other modules (and,
thus, need to load a different TOC base value into %r2), need to restore the
old value after the call. The old value is saved by the .plt code, and the
caller only needs to include a nop instruction after the call, which the linker
will transform into a TOC restore if necessary.

In order to do this the relocation handler needs two things:

 1. It needs to know whether the call instruction it is modifying is targeting
    a .plt stub that will load a new TOC base value (necessitating a restore after
    the call).

 2. It needs to know where the buffer ends, so that it does not accidentally
    run off the end of the buffer when looking for the 'nop' instruction after the
    call.

Given these two pieces of information, we can insert the restore instruction in
place of the following nop when necessary.

llvm-svn: 250110

As pointed out by Rui (post-commit review), we need to always return based on
the section type when the types differ to ensure a strict weak ordering.

llvm-svn: 250109

Adds LLVM_PROFDATA_FILE option to allow specifying a profile data file to be used during compilation of LLVM and subprojects.

llvm-svn: 250108

Fix the buildbot; this test also requires ppc target support.

llvm-svn: 250107

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

llvm-svn: 250106

llvm-svn: 250105

Now that the target relocation handle will see R_PPC64_TOC, fix the test case
accordingly.

llvm-svn: 250104

This is essentially pattern-matching against the x86 target, and generates the
analogous PPC64 relocation.

llvm-svn: 250102

This is mostly an adaptation of the code in LLVM's
lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp, and handles a sufficient
number of relocations to link a 'hello world' program on big-Endian PPC64/Linux
(ELF v1 ABI).

llvm-svn: 250101