Changes

Looks like XToolchainBuilder wants forward slash path separator for
llvm-ar path.

Fix build with shared libraries. NFC.
- Dependent components need linking directly.

ARM: Don't emit R_ARM_NONE relocations to compact unwinding decoders in
.ARM.exidx on Android.
These relocations are specified by the ARM EHABI (section 6.3). As I
understand it, their purpose is to accommodate unwinder implementations
that wish to reduce code size by placing the implementations of the
compact unwinding decoders in a separate translation unit, and using
extern weak symbols to refer to them from the main unwinder
implementation, so that they are only linked when something in the
binary needs them in order to unwind.
However, neither of the unwinders used on Android (libgcc, LLVM
libunwind) use this technique, and in fact emitting these relocations
ends up being counterproductive to code size because they cause a copy
of the unwinder to be statically linked into most binaries, regardless
of whether it is actually needed. Furthermore, these relocations create
circular dependencies
(between libc and the unwinder) in cases where the unwinder is
dynamically linked and libc contains compact unwind info.
Therefore, deviate from the EHABI here and stop emitting these
relocations on Android.
Differential Revision: https://reviews.llvm.org/D70027

[ObjectFileMachO] Fix the build for __arm64__.
Catch up with an API change.

[llvm-objcopy][COFF] Implement --redefine-sym and --redefine-syms
The parsing error tests in ELF/redefine-symbols.test are not specific to
ELF. Move them to redefine-symbols.test. Add COFF/redefine-symbols.test
for COFF specific tests.
Also fix the documentation regarding --redefine-syms: the old and new 
names are separated by whitespace, not an equals sign.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D70036

[LLDB][Formatters] Re-enable std::function formatter with fixes to
improve non-cached lookup performance
Performance issues lead to the libc++ std::function formatter to be
disabled. We addressed some of those performance issues by adding
caching see D67111 This PR fixes the first lookup performance by not
using FindSymbolsMatchingRegExAndType(...) and instead finding the
compilation unit the std::function wrapped callable should be in and
then searching for the callable directly in the CU.
Differential Revision: https://reviews.llvm.org/D69913

[AST] Use an explicit copy in a range-based for
The AssociationIteratorTy type will be copied in a range-based for loop. 
Make the copy explicit to avoid the -Wrange-loop-analysis warning.
This avoids new warnings due to D68912 adds -Wrange-loop-analysis to
-Wall.
Differential Revision: https://reviews.llvm.org/D70045

[OpenMP] Use an explicit copy in a range-based for
The std::pair<const clang::ValueDecl *,
llvm::ArrayRef<clang::OMPClauseMappableExprCommon::MappableComponent>> 
type will be copied in a range-based for loop. Make the copy explicit to 
avoid the -Wrange-loop-analysis warning.
This avoids new warnings due to D68912 adds -Wrange-loop-analysis to
-Wall.
Differential Revision: https://reviews.llvm.org/D70046

[Analyzer] Use a reference in a range-based for
Let the checkers use a reference instead of a copy in a range-based for
loop.
This avoids new warnings due to D68912 adds -Wrange-loop-analysis to
-Wall.
Differential Revision: https://reviews.llvm.org/D70047

[CodeGen] Fix getArrayAccessFor crashes as in bug 32534 with
-polly-vectorizer=polly.
Root cause is VectorBlockGenerator::copyStmt iterates all instructions 
in basic block, however some load instructions may be not unnecessary 
thus removed by simplification. As a result, these load instructions 
don't have a corresponding array.
Looking at BlockGenerator::copyBB, it only iterates instructions list of
ScopStmt. Given it must be a block type scop in case of vectorization, I
think we should do the same in VectorBlockGenerator::copyStmt.
Patch by bin.narwal <bin.narwal@gmail.com>
Differential Revision: https://reviews.llvm.org/D70076

[AArch64] Fix addressing mode predicates
Fix predicates related to the register offset addressing mode.

[AArch64] Update for Exynos
Fix the modeling for loads and stores using the register offset
addresing mode.

[LLDB] Always remove debugserver from LLVM_DISTRIBUTION_COMPONENTS
Centralize the logic to remove debugserver from 
LLVM_DISTRIBUTION_COMPONENTS when LLDB_USE_SYSTEM_DEBUGSERVER is 
enabled. Now this happens regardless of whether the tests are enabled.

Allow additional file suffixes/extensions considered as source in main
include grouping
Summary: By additional regex match, grouping of main include can be
enabled in files that are not normally considered as a C/C++ source
code. For example, this might be useful in templated code, where
template implementations are being held in *Impl.hpp files. On the
occassion, 'assume-filename' option description was reworded as it was
misleading. It has nothing to do with `style=file` option and it does
not influence sourced style filename.
Reviewers: rsmith, ioeric, krasimir, sylvestre.ledru, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, cfe-commits
Patch by:  furdyna
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67750

[GVNHoist] Preserve AAResults.
Resolves PR38906, PR40898.

[LLDB] Fix/silence CMake developer warning for LLDB framework.
This fixes the following warning for developers:
  Target 'liblldb' was changed to a FRAMEWORK sometime after install(). 
This
 may result in the wrong install DESTINATION.  Set the FRAMEWORK
property
 earlier.
The solution is to pass the FRAMEWORK flag to add_lldb_library and set 
the target property before install(). For now liblldb is the only 
customer.

[GlobalsAA] Restrict ModRef result if any internal method has its
address taken.
Summary: If there are any internal methods whose address was taken,
conclude there is nothing known in relation of any other internal method
and a global.
Reviewers: nlopes, sanjoy.google
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69690

[BPF] generate BTF_KIND_VARs for all non-static globals
Enable to generate BTF_KIND_VARs for non-static default-section globals
which is not allowed previously. Modified the existing test case to
accommodate the new change.
Also removed unused linkage enum members VAR_GLOBAL_TENTATIVE and 
VAR_GLOBAL_EXTERNAL.
Differential Revision: https://reviews.llvm.org/D70145

Add -Wtautological-compare to -Wall
Some warnings in -Wtautological-compare subgroups are DefaultIgnore. 
Adding this group to -Wmost, which is part of -Wall, will aid in their 
discoverability.
Differential Revision: https://reviews.llvm.org/D69292

Fix include guard and properly order __deregister_frame_info.
Summary: This patch fixes two problems with the crtbegin.c as written:
1. In do_init, register_frame_info is not guarded by a #define, but in 
do_fini, deregister_frame_info is guarded by #ifndef 
CRT_HAS_INITFINI_ARRAY. Thus when CRT_HAS_INITFINI_ARRAY is not defined,
frames are registered but then never deregistered.
The frame registry mechanism builds a linked-list from the .so's static
variable do_init.object, and when the .so is unloaded, this memory
becomes invalid and should be deregistered.
Further, libgcc's crtbegin treats the frame registry as independent from
the initfini array mechanism.
This patch fixes this by adding a new #define,
"EH_USE_FRAME_INFO_REGISTRY", which is set by the cmake option 
COMPILER_RT_CRT_USE_EH_FRAME_REGISTRY Currently, do_init calls 
register_frame_info, and then calls the binary's constructors. This 
allows constructors to safely use libunwind. However, do_fini calls 
deregister_frame_info and then calls the binary's destructors. This 
prevents destructors from safely using libunwind.
This patch also switches that ordering, so that destructors can safely 
use libunwind. As it happens, this is a fairly common scenario for 
thread sanitizer.

[X86] Only pass v64i8/v32i16 as v16i32 on non-avx512bw targets if the
v16i32 type won't be split by prefer-vector-width=256
Otherwise just let the v64i8/v32i16 types be split to v32i8/v16i16.
In reality this shouldn't happen because it means we have a 512-bit 
vector argument, but min-legal-vector-width says a value less than 512.
But a 512-bit argument should have been factored into the preferred
vector width.

[X86] Don't consider v64i1 as a legal type unless v64i8 is also a legal
type.
This avoids some nasty issues with argument passing and lowering of 
arbitrary v64i8 shuffles.

Add a shim for setenv on PS4 since it does not exist.
A few years back a similar change was made for getenv since neither
function is supported on the PS4 platform.
Recently, commit d889d1e added a call to setenv in compiler-rt which was
causing linking errors because the symbol was not found. This fixes that
issue by putting in a shim similar to how we previously dealt with the
lack of getenv.
Differential Revision: https://reviews.llvm.org/D70033

[LLDB] Remove debug message in AddLLDB.cmake

[LLDB] Only set FRAMEWORK when we're actually building a framework.

Temporarily Revert "Reapply [LVI] Normalize pointer behavior" as it's
broken python 3.6.
Reverting to figure out if it's a problem in python or the compiler for
now.
This reverts commit 885a05f48a5d320946c89590b73a764e5884fe4f.

Temporarily disable test.

[Sema] Add MacroQualified case for FunctionTypeUnwrapper
This is a fix for PR43315. An assertion error is hit for this minimal
example:
```
//clang -cc1 -triple x86_64-- -S tstVMStructRC-min.cpp int (a b)();  //
Assertion `Chunk.Kind == DeclaratorChunk::Function' failed.
```
This is because we do not cover the case in the FunctionTypeUnwrapper
where it receives a MacroQualifiedType. We have not run into this
earlier because this is a unique case where the __attribute__ contains
both __cdecl__ and
__regparm__ (in that order), and we are compiling for x86_64. Changing
the architecture or the order of __cdecl__ and __regparm__ does not
raise the assertion.
Differential Revision: https://reviews.llvm.org/D67992

Don't assume that the clang binary's resolved name includes the string
'clang'.
This is not true in practice in some content-addressed file systems.

[LLDB] Add core definition for armv8l and armv7l
This patch adds core definitions in lldb ArchSpecs for armv8l and armv7l
cores.
This was needed because on Linux running on 32-bit Arm v8 we are
returned armv8l in case we are running 32-bit sysroot on 64bit kernel.
In case of 32-bit kernel and 32-bit sysroot running on arm v8 hardware
we are returned armv7l. This is quite common when we run 32 bit arm
using docker container.
Signed-off-by: Muhammad Omair Javaid <omair.javaid@linaro.org>
Differential Revision: https://reviews.llvm.org/D69904

[GlobalsAA] Reenable test.

AMDGPU Reduce reported maximum group size to 1024
While some targets allow encoding 2048, this was never tested or 
supported.

AMDGPU: Switch backend default max workgroup size to 1024
Previously this would default to 256, not the maximum supported size of
1024. Using a maximum lower than the hardware maximum requires language
runtimes to enforce this limit for correctness, which no language has
correctly done. Switch the default to the conservatively correct
maximum, and force frontends to opt-in to the more optimal 256 default
maximum.
I don't really understand why the changes in occupancy-levels.ll 
increased the computed occupancy, which I expected to decrease. I'm not
sure if these tests should be forcing the old maximum.

Looks like XToolchainBuilder wants forward slash path separator for
llvm-ar path.