Set cmake policy CMP0068=NEW, if available, and set
"CMAKE_BUILD_WITH_INSTALL_NAME_DIR=On" globally to
maintain current behavior.

This is needed to suppress warnings on OSX starting with cmake version
3.9.6.

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

llvm-svn: 323404

llvm-svn: 323403

MMX instrutions all start with MMX_ so the 64 isn't needed for disambigutation.
SSE/AVX1 instructions are assumed 128-bit so we don't need to say 128.
AVX2 instructions should use a Y to indicate 256-bits.

llvm-svn: 323402

These were treated as optional suffixes, but the regular expressions are already prefix matches so this is unnecessary. It breaks the binary search optimization in tablegen due to the top level question mark.

llvm-svn: 323401

https://reviews.llvm.org/D42439

Add Instcombine like matchers for MachineInstructions. There are only
globalISel matchers for now.

llvm-svn: 323400

We can just use a member variable in MemoryRegion.

llvm-svn: 323399

first argument.

This makes lookupFlags more consistent with lookup (which takes the query as the
first argument) and composes better in practice, since lookups are usually
linearly chained: Each lookupFlags can populate the result map based on the
symbols not found in the previous lookup. (If the maps were returned rather than
passed by reference there would have to be a merge step at the end).

llvm-svn: 323398

This fixes:
src/cxa_default_handlers.cpp:25:13: error: unused function 'demangling_terminate_handler' [-Werror,-Wunused-function]

Patch by Thomas Anderson!

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

llvm-svn: 323397

This is similar to how we handle MemRegion.

llvm-svn: 323396

llvm-svn: 323395

llvm-svn: 323394

http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/17264

NFC.

llvm-svn: 323393

https://reviews.llvm.org/D41373

The various components are

GICombinerHelper contains transformations that are common to all
targets. Targets can pick and choose which transformations (at
function/opcode granularity) each pass uses via configuring a
GICombinerInfo.

GICombiner contains some common code and it does the traversal,
driving of combines, worklist management and iterating until
convergence.

GICombinerInfo is an interface with a virtual method called combine.
The combiner info will allow targets to pick and choose (or
implement their own specific combines). CombineInfos can make
use of available combines in GICombineHelper to configure the
transformations for a particular pass. Currently this approach allows
cherry picking transformations from helpers (at function/opcode
granularity) and also allows early returning on specific
transformations. Targets also get to prioritize whether target specific
combines run before/after the opt-in generic combines. Ideally we would
like this part to be configured by both C++ and Tablegen. The
CombinerInfo also has a field which indicates how to deal with
IllegalOps (ie - should we allow to create them/or legalize them?).

A CombinerPass would configure a CombinerInfo, create the GICombiner
with the Info, and call
GICombiner::combineMachineInstrs(MachineFunction&).
This organization is very similar to the GISelLegalizer.

llvm-svn: 323392

Collected statistics for the number of patterns emitted can be
incorrect because rules can be grouped if OptimizeMatchTable
is enabled. Increase the counter in RuleMatcher::emit(...)
to avoid that.

llvm-svn: 323391

There was a bug in the implementation of splice where the container
sizes were updated before decrementing one of the iterators. Afterwards,
the result of decrementing the iterator was flagged as UB by the debug
implementation because the container was reported to be empty.

This patch fixes that bug by delaying the updating of the container
sizes until after the iterators have been correctly constructed.

llvm-svn: 323390

Fix missing return in __tuple_leaf::__can_bind_reference when __reference_binds_to_temporary added in r323380.

llvm-svn: 323389

functions/methods that return JITSymbols.

lookupFlagsWithLegacyFn takes a SymbolNameSet and a legacy lookup function and
returns a LookupFlagsResult. It uses the legacy lookup function to search for
each symbol. If found, getFlags is called on the symbol and the flags added to
the SymbolFlags map. If not found, the symbol is added to the SymbolsNotFound
set.

lookupWithLegacyFn takes an AsynchronousSymbolQuery, a SymbolNameSet and a
legacy lookup function. Each symbol in the SymbolNameSet is searched for via the
legacy lookup function. If it is found, its getAddress function is called
(triggering materialization if it has not happened already) and the resulting
mapping stored in the query. If it is not found the symbol is added to the
unresolved symbols set which is returned at the end of the function. If an
error occurs during legacy lookup or materialization it is passed to the
query via setFailed and the function returns immediately.

llvm-svn: 323388

Summary: As NetBSD, FreeBSD needs execinfo for backtrace's matters.

Patch by: David CARLIER.

Reviewers: joerg, vitalybuka

Reviewed By: vitalybuka

Subscribers: emaste, krytarowski, cfe-commits

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

llvm-svn: 323387

Summary:
Currently all platforms are using the `scudo_interceptors.cpp` interceptors.

We might to come up with platform specific interceptors when/if we get Apple &
Windows, but as of now, that allows for Fuchsia to use them.

`scudo_new_delete.cpp` didn't have the `#if SANITIZER_LINUX` so it's good to go.

Reviewers: alekseyshl, flowerhack

Reviewed By: flowerhack

Subscribers: delcypher, #sanitizers, llvm-commits

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

llvm-svn: 323386

llvm-svn: 323385

llvm-svn: 323384

[TableGen] Add a way of getting the number of generic opcodes without including modular CodeGen headers.

This is a bit of a hack, but removes a cycle that broke modular builds
of LLVM. Of course the cycle is still there in form of a dependency
on the .def file.

llvm-svn: 323383

Do not attempt to get the pointee of void* while generating a bug report 
(otherwise it will trigger an assert inside RegionStoreManager::getBinding 
assert(!T->isVoidType() && "Attempting to dereference a void pointer!")).

Test plan: make check-all

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

llvm-svn: 323382

Summary:
Use corutine function arguments to initialize a promise type, but only
if the promise type defines a constructor that takes those arguments.
Otherwise, fall back to the default constructor.

Test Plan: check-clang

Reviewers: rsmith, GorNishanov, eric_niebler

Reviewed By: GorNishanov

Subscribers: toby-allsopp, lewissbaker, EricWF, cfe-commits

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

llvm-svn: 323381

Summary:
See https://bugs.llvm.org/show_bug.cgi?id=20855

Libc++ goes out of it's way to diagnose `std::tuple` constructions which are UB due to lifetime bugs caused by reference creation. For example:

```
// The 'const std::string&' is created *inside* the tuple constructor, and its lifetime is over before the end of the constructor call.
std::tuple<int, const std::string&> t(std::make_tuple(42, "abc"));
```

However, we are over-aggressive and we incorrectly diagnose cases such as:

```
void foo(std::tuple<int const&, int const&> const&);
foo(std::make_tuple(42, 42));
```

This patch fixes the incorrectly diagnosed cases, as well as converting the diagnostic to use the newly added Clang trait `__reference_binds_to_temporary`. The new trait allows us to diagnose cases we previously couldn't such as:

```
std::tuple<int, const std::string&> t(42, "abc");
```

Reviewers: rsmith, mclow.lists

Reviewed By: rsmith

Subscribers: cfe-commits

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

llvm-svn: 323380

Previously, we were ensuring that the "output index" for
InputFunctions was unique across all symbols that referenced
a function body, but allowing the same function body to have
multiple table indexes.

Now, we use the same mechanism for table indexes as we already
do for output indexes, ensuring that each InputFunction is only
placed in the table once.

This makes the LLD output table denser and smaller, but should
not change the behaviour.

Note that we still need the `Symbol::TableIndex` member, to
store the table index for function Symbols that don't have an
InputFunction, i.e. for address-taken imports.

Patch by Nicholas Wilson!

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

llvm-svn: 323379

Previously llvm was using 0 as the first table index for wasm object
files but now that has switched to 1 we can have the output of lld
do the same and simplify the code.

Patch by Nicholas Wilson!

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

llvm-svn: 323378

The only part of the datalayout that should matter for these tests
is the part that specifies the legal int widths ('n*'). But there
was a bug - that part of the string was not correctly separated with
the expected '-' character, so we were testing as if there were no
legal int widths at all. Removed the leading cruft so we have some 
legal ints to test with.

I noticed this while testing a potential change to the way we 
transform shifts and sexts in D42424.

llvm-svn: 323377

In order to provide more test coverage for inlined operator new(), add more
run-lines to existing test cases, which would trigger our fake header
to provide a body for operator new(). Most of the code should still behave
reasonably. When behavior intentionally changes, #ifs are provided.

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

llvm-svn: 323376

This patch adds a LambdaSymbolResolver convenience utility that can create an
orc::SymbolResolver from a pair of function objects that supply the behavior for
the lookupFlags and lookup methods.

This class plays the same role for orc::SymbolResolver as the legacy
LambdaResolver class plays for LegacyJITSymbolResolver, and will replace the
latter class once all ORC APIs are migrated to orc::SymbolResolver.

This patch also adds some documentation for the orc::SymbolResolver class as
this was left out of the original commit.

llvm-svn: 323375

The code in EmitFunctionEntryCode needs to know the maximum stack
alignment, but it runs very early in the selection process (before
lowering). The final stack alignment may change during lowering, so
the code needs to be moved to where the alignment is known.

llvm-svn: 323374

This allows the analyzer to analyze ("inline") custom operator new() calls and,
even more importantly, inline constructors of objects that were allocated
by any operator new() - not necessarily a custom one.

All changes in the tests in the current commit are intended improvements,
even if they didn't carry any explicit FIXME flag.

It is possible to restore the old behavior via

  -analyzer-config c++-allocator-inlining=false

(this flag is supported by scan-build as well, and it can be into a clang
--analyze invocation via -Xclang .. -Xclang ..). There is no intention to
remove the old behavior for now.

Differential Revision: https://reviews.llvm.org/D42219
rdar://problem/12180598

llvm-svn: 323373

They would be fixed in a later patch but they shouldn't have been introduced.

llvm-svn: 323372

The tablegen imported patterns for sext(load(a)) don't check for single uses
of the load or delete the original after matching. As a result two loads are
left in the generated code. This particular issue will be fixed by adding
support for a G_SEXTLOAD opcode in future.

There are however other potential issues around this that wouldn't be fixed by
a G_SEXTLOAD, so until we have a proper solution we don't try to handle volatile
loads at all in the AArch64 selector.

Fixes/works around PR36018.

llvm-svn: 323371

I.e. not after. In the c++-allocator-inlining=true mode, we need to make the
assumption that the conservatively evaluated operator new() has returned a
non-null value. Previously we did this on CXXNewExpr, but now we have to do that
before calling the constructor, because some clever constructors are sometimes
assuming that their "this" is null and doing weird stuff. We would also crash
upon evaluating CXXNewExpr when the allocator was inlined and returned null and
had a throw specification; this is UB even for custom allocators, but we still
need not to crash.

Added more FIXME tests to ensure that eventually we fix calling the constructor
for null return values.

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

llvm-svn: 323370

Apparently checking the pass structure isn't enough to ensure that we don't fall
back to FastISel, as it's set up as part of the SelectionDAGISel.

llvm-svn: 323369

This broke swift builds.

Thanks for the post-commit review of Chris Bieneman and Davide Italiano!

llvm-svn: 323368

As discussed in D41484, PMADDWD for 'zero extended' vXi32 is nearly always a better option than PMULLD:
On SNB it will result in code that isn't any faster, but not any slower so we may as well keep it.
On KNL it only has half the throughput, so I've disabled it on there - ideally there'd be a better way than this.

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

llvm-svn: 323367

Since SyntheticSection::getParent() may return null, dereferencing
this pointer in ARMExidxSentinelSection::empty() call from
removeUnusedSyntheticSections() results in crashes when linking ARM
binaries.

Patch by vit9696!

llvm-svn: 323366

Thanks to Teresa Johnson for the suggestion.

llvm-svn: 323365