Remarks are usually emitted per-TU, and for generating a standalone
remark file that can be shipped with the linked binary we need some kind
of tool to merge everything together.

The remarks::RemarkLinker class takes care of this and:

* Deduplicates remarks
* Filters remarks with no debug location
* Merges string tables from all the entries

As an output, it provides an iterator range that can be used to
serialize the remarks to a file.

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

I forgot to git add it when I committed for Evgeniy.

This patch adds flag "mayRaiseFPException" , FPCW and FPSW for X87 instructions which could raise
float exception.

Patch by LiuChen. With a couple small fixes from me.

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

Summary:
Fixes an ISel failure when a splatted load is used more than once. The
failure was due to the hacks we were doing in ISel lowering to
preserve the original load as the operand of a LOAD_SPLAT node. The
fix is to properly lower the splatted use of the load to a separate
LOAD_SPLAT node.

Reviewers: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits

Tags: #llvm

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

Fix test case for Darwin builds.

Summary:
cferris@ found an issue due to the new Secondary free list behavior
and unfortunately it's completely my fault. The issue is twofold:

- I lost track of the (major) fact that the Combined assumes that
  all chunks returned by the Secondary are zero'd out apprioriately
  when dealing with `ZeroContents`. With the introduction of the
  freelist, it's no longer the case as there can be a small portion
  of memory between the header and the next page boundary that is
  left untouched (the rest is zero'd via release). So the next time
  that block is returned, it's not fully zero'd out.
- There was no test that would exercise that behavior :(

There are several ways to fix this, the one I chose makes the most
sense to me: we pass `ZeroContents` to the Secondary's `allocate`
and it zero's out the block if requested and it's coming from the
freelist. The prevents an extraneous `memset` in case the block
comes from `map`. Another possbility could have been to `memset`
in `deallocate`, but it's probably overzealous as all secondary
blocks don't need to be zero'd out.

Add a test that would have found the issue prior to fix.

Reviewers: morehouse, hctim, cferris, pcc, eugenis, vitalybuka

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

Summary: This fixes issue #163, among other improvements to go-to-definition.

Reviewers: sammccall

Subscribers: jkorous, mgrang, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

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

We currently don't simplify these, because getPredicateAt() does
not use block values.

Summary:
The SIMD spec does not include i64x2 comparisons, so they need to be
expanded. Using setOperationAction to expand them also causes f64x2
comparisons to be expanded, so setCondCodeAction needs to be used
instead. But since there are no legal condition codes, the legalizer
does not know how to expand the comparisons. We therefore manually
unroll the operation, taking care to fill each lane with -1 or 0
rather than 1 or 0 for consistency with the other vector comparisons.

Reviewers: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits

Tags: #llvm

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

Previously, given a CompilationDatabase with two commands for the same
source file we would report that file twice with the union of the
dependencies for each command both times.

This was due to the way `ClangTool` runs actions given an input source
file (see the comment in `DependencyScanningTool.cpp`). This commit adds
a `SingleCommandCompilationDatabase` that is created with each
`CompileCommand` in the original CDB, which is then used for each
`ClangTool` invocation. This gives us a single run of
`DependencyScanningAction` per `CompileCommand`.

I looked at using `AllTUsToolExecutor` which is a parallel tool
executor, but I'm not sure it's suitable for `clang-scan-deps` as it
does a lot more sharing of state than `AllTUsToolExecutor` expects.

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

I built locally with the latest MSVC in c++14 and c++17, but it does not
complain for me. Osman Zakir on llvm-dev reports that they run into
compile errors here.

In any case, it seems prefereable to reuse clang's LLVM.h header to
bring in llvm::Optional and Expected.

Summary:
This is required to update tests that make use of builtin headers. To fix
this use the same command expansion as lit does for %clang_cc1. I tested
this by updating clang/test/CodeGen/arm-mve-intrinsics/scalar-shifts.c.
%clang_cc1 will now expand to `clang -cc1 -internal-isystem
$LLVM_BUILD/lib/clang/$VERSION/include -nostdsysteminc`.

Reviewers: MaskRay

Reviewed By: MaskRay

Subscribers: kristof.beyls, dmgreen, llvm-commits

Tags: #llvm

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

Summary:
xcodebuild does not work unless XCode is installed whereas xcrun also work
when only the Command Line Tools are installed. Unlike the check for the
version (D69610), this did not cause an erro for me since the fallback to
/usr/include for the OSX sysroot worked.

Reviewers: yln, delcypher

Reviewed By: yln

Subscribers: dberris, mgorny, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

Summary:
Starting with 8a5bfbe6 (D68292) this file
unconditionally uses xcodebuild to get the SDK version. On my system this
always fails with
`xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance`

Reviewers: delcypher, yln

Reviewed By: delcypher, yln

Subscribers: dberris, mgorny, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

Fixes stage2 cross compilation.

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

Move TargetLoweringBase::isSuitableForJumpTable from
llvm/CodeGen/TargetLowering.h to .cpp, to avoid the undefined reference
from all LLVM${Target}ISelLowering.cpp.

Another fix is to add a dependency on TransformUtils to all
lib/Target/$Target/LLVMBuild.txt, but that is too disruptive.

Summary:
Sometimes an allocation stack trace is not very informative. Provide a
way to replace it with a stack trace of the user's choice.

Reviewers: pcc, kcc

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

[X86] Remove FSIN/FCOS isel patterns and the pseudo instructions that they selected for the FP stackifier.

We always expand these to libcalls so get rid of the last vestiges
of using the instructions.

This reverts commit df899f22.
Looks like ec66603a was reverted recently.

Fix the costs of `add` and `orr` with an immediate operand.

Summary:
(Split of off D67120)

TargetLowering/TargetTransformationInfo/SwitchLoweringUtils changes for profile
guided size optimization.

Reviewers: davidxl

Subscribers: eraman, hiraditya, haicheng, llvm-commits

Tags: #llvm

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

Before we did not follow casts and geps when we looked at the users of a
pointer in the pointers must-be-executed-context. This caused us to fail
to determine if it was accessed for sure. With this change we follow
such users now.

The above extension exposed problems in getKnownNonNullAndDerefBytesForUse
which did not always check what the base pointer was. We also did not
handle negative offsets as conservative as we have to without explicit
loop handling. Finally, we should not derive a huge number if we access
a pointer that was traversed backwards first.

The problems exposed by this functional change are already tested in the
existing test cases as is the functional change.

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

Summary:
Patch adds support for vectorization of the jumbled stores. The value
operands are vectorized and then shuffled in the right order before
store.

Reviewers: RKSimon, spatel, hfinkel, mkuper

Subscribers: llvm-commits

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

Summary:
In order to get context sensitivity from isKnownNonZero we need to
provide a context instruction *and* a dominator tree. The latter is
passed now to which actually allows to remove some initialization code.

Tests taken from PR43833.

Reviewers: uenoku, sstefan1

Subscribers: hiraditya, bollu, llvm-commits

Tags: #llvm

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

Same as D60846 but with a fix for the problem encountered there which
was a missing context adjustment in the handling of PHI nodes.

The test that caused D60846 to be reverted was added in e15ab8f2.

Reviewers: nikic, nlopes, mkazantsev,spatel, dlrobertson, uabelho, hakzsam

Subscribers: hiraditya, bollu, llvm-commits

Tags: #llvm

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

Breaks build bots

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

Summary:
Instead of filling out a std::string and returning a bool to indicate
success, returning a std::string directly and testing to see if it's
empty seems like a cleaner solution overall.

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

This is in preparation of D69571.

The users of build_function_body_dictionary and add_checks need to be
adjusted after the changes in UpdateTestChecks/common.py.

Slightly decreases the time I need to parse the test summary.

Without this patch, when using lit's internal shell, if `env` on a lit
RUN line calls `cd`, `mkdir`, or any of the other in-process shell
builtins that lit implements, lit accidentally searches for the latter
as an external executable.

This patch puts such builtins in a map so that boilerplate for them
need be implemented only once.  This patch moves that handling after
processing of `env` so that `env` calling such a builtin can be
detected.  Finally, because such calls appear to be useless, this
patch takes the safe approach of diagnosing them rather than
supporting them.

Reviewed By: probinson, mgorny, rnk

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

These fail parsing command line arguments.

Update TargetTransformInfo to allow AVX1 to use YMM registers for memcmp.

This is a follow up to D68632 which enabled XOR compares which made this possible.

https://reviews.llvm.org/D69658