Changes

[xray] Add xray-ignore-loops option
XRay allows tuning by minimum function size, but also always instruments 
functions with loops in them.  If the minimum function size is set to a 
large value the loop instrumention ends up causing most functions to be 
instrumented anyway.  This adds a new flag, xray-ignore-loops, to
disable the loop detection logic.
Differential Revision: https://reviews.llvm.org/D72659

[clang][xray] Add -fxray-ignore-loops option
XRay allows tuning by minimum function size, but also always instruments 
functions with loops in them. If the minimum function size is set to a 
large value the loop instrumention ends up causing most functions to be 
instrumented anyway. This adds a new flag, -fxray-ignore-loops, to
disable the loop detection logic.
Differential Revision: https://reviews.llvm.org/D72873

[xray] Allow instrumenting only function entry and/or only function exit
Extend -fxray-instrumentation-bundle to split function-entry and 
function-exit into two separate options, so that it is possible to 
instrument only function entry or only function exit.  For use cases 
that only care about one or the other this will save significant
overhead and code size.
Differential Revision: https://reviews.llvm.org/D72890

Pass length of string in Go binding of CreateCompileUnit

[mlir] [VectorOps] Rename Utils.h into VectorUtils.h
Summary: First step towards the consolidation of a lot of vector related
utilities that are now all over the place
(or even duplicated).
Reviewers: nicolasvasilache, andydavis1
Reviewed By: nicolasvasilache, andydavis1
Subscribers: merge_guards_bot, mehdi_amini, rriddle, jpienaar, burmako,
shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, liufengdb,
llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72955

[InstSimplify] add test for select of FP constants; NFC

[InstSimplify] add test for select of vector constants; NFC

hwasan: Move .note.hwasan.globals note to hwasan.module_ctor comdat.
As of D70146 lld GCs comdats as a group and no longer considers notes in 
comdats to be GC roots, so we need to move the note to a comdat with a
GC root section (.init_array) in order to prevent lld from discarding
the note.
Differential Revision: https://reviews.llvm.org/D72936

[libc++] Optimize / partially inline basic_string copy constructor
Splits copy constructor up inlining short initialization, outlining long 
initialization into __init_long() which is the externally instantiated
slow path initialization.
Subsequently changing the copy ctor to be inlined (not externally
instantiated) provides significant speed ups for short string
initialization.
Generated code given:
void StringCopyCtor(void* mem, const std::string& s) {
   std::string*p = new(mem) std::string{s};
}
asm:
       cmp     byte ptr [rsi + 23], 0
       js      .LBB0_2
       mov     rax, qword ptr [rsi + 16]
       mov     qword ptr [rdi + 16], rax
       movups  xmm0, xmmword ptr [rsi]
       movups  xmmword ptr [rdi], xmm0
       ret
.LBB0_2:
       jmp     std::basic_string::__init_long # TAILCALL
Benchmark: BM_StringCopy_Empty                                          
5.19ns ± 6%             1.50ns ± 8%  -71.02%        (p=0.000 n=10+10) 
BM_StringCopy_Small                                           5.14ns ±
8%             1.53ns ± 7%  -70.17%        (p=0.000 n=10+10) 
BM_StringCopy_Large                                           18.9ns ±
0%             19.3ns ± 0%   +1.92%        (p=0.000 n=10+10) 
BM_StringCopy_Huge                                             309ns ±
1%              316ns ± 5%     ~            (p=0.633 n=8+10)
Patch from Martijn Vels (mvels@google.com) Reviewed as D72160.

[mlir][Linalg] Extend linalg vectorization to MatmulOp
Summary: This is a simple extension to allow vectorization to work not
only on GenericLinalgOp but more generally across named ops too. For
now, this still only vectorizes matmul-like ops but is a step towards
more generic vectorization of Linalg ops.
Reviewers: ftynse
Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen,
antiagainst, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb,
llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72942

[lldb/Docs] Fix formatting for the variable formatting page

[libcxx] Introduce LinuxRemoteTI for remote testing
Summary: This patch adds a new target info object called LinuxRemoteTI. 
Unlike LinuxLocalTI, which asks the host system about various things 
like available locales, distribution name etc. which don't make sense if
we're testing on a remote board, LinuxRemoteTI uses SSHExecutor to get
information from the target system.
Reviewers: jroelofs, ldionne, bcraig, EricWF, danalbert, mclow.lists
Reviewed By: jroelofs
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D72847

[CMake] Use LinuxRemoteTI instead of LinuxLocalTI in CrossWinToARMLinux
cmake cache
Summary: Depends on D72847
Reviewers: vvereschaka, aorlov, andreil99
Reviewed By: vvereschaka
Subscribers: mgorny, kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72850

[profile] Support counter relocation at runtime
This is an alternative to the continous mode that was implemented in 
D68351. This mode relies on padding and the ability to mmap a file over 
the existing mapping which is generally only available on POSIX systems 
and isn't suitable for other platforms.
This change instead introduces the ability to relocate counters at 
runtime using a level of indirection. On every counter access, we add a 
bias to the counter address. This bias is stored in a symbol that's 
provided by the profile runtime and is initially set to zero, meaning no 
relocation. The runtime can mmap the profile into memory at abitrary 
location, and set bias to the offset between the original and the new 
counter location, at which point every subsequent counter access will be 
to the new location, which allows updating profile directly akin to the 
continous mode.
The advantage of this implementation is that doesn't require any special 
OS support. The disadvantage is the extra overhead due to additional 
instructions required for each counter access (overhead both in terms of 
binary size and performance) plus duplication of counters (i.e. one copy 
in the binary itself and another copy that's mmapped).
Differential Revision: https://reviews.llvm.org/D69740

hwasan: Remove dead code. NFCI.
Differential Revision: https://reviews.llvm.org/D72896

[CMake] Prefer multi-target variables over generic target variables in
runtimes build
Runtimes variables in a multi-target environment are defined like:
RUNTIMES_target_VARIABLE_NAME RUNTIMES_target+multi_VARIABLE_NAME
In my case, I have a downstream runtimes cache that does the following:
set(RUNTIMES_${target}+except_LIBCXXABI_ENABLE_EXCEPTIONS ON CACHE BOOL
"") set(RUNTIMES_${target}_LIBCXX_ENABLE_EXCEPTIONS OFF CACHE BOOL "")
I found that I was always getting the 'target' variable value (OFF) in 
my 'target+except' build, which was unexpected.  This behavior was 
caused by the loop in llvm/runtimes/CMakeLists.txt that runs through all 
variable names, adding '-DVARIABLE_NAME=' options to the subsequent 
external project's cmake command.
The issue is that the loop does a single pass, such that if the 'target' 
value appears in the cache after the 'target+except' value, the 'target' 
value will take precedence. I suggest in my change here that the more 
specific 'target+except' value should take precedence always, without 
relying on CMake cache ordering.
Differential Revision: https://reviews.llvm.org/D71570
Patch By: JamesNagurne

[MemDepAnalysis/VNCoercion] Move static method to its only use. [NFCI]
Static method MemoryDependenceResults::getLoadLoadClobberFullWidthSize 
does not have or use any info specific to MemoryDependenceResults. Move
it to its only user: VNCoercion.

Merge memtag instructions with adjacent stack slots.
Summary: Detect a run of memory tagging instructions for adjacent stack
frame slots, and replace them with a shorter instruction sequence
* replace STG + STG with ST2G
* replace STGloop + STGloop with STGloop
This code needs to run when stack slot offsets are already known, but
before FrameIndex operands in STG instructions are eliminated; that's
the reason for the new hook in PrologueEpilogue.
This change modifies STGloop and STZGloop pseudos to take the size as an 
immediate integer operand, and adds _untied variants of those pseudos 
that are allowed to take the base address as a FI operand. This is
needed to simplify recognizing an STGloop instruction as operating on a
stack slot post-regalloc.
This improves memtag code size by ~0.25%, and it looks like an
additional ~0.1% is possible by rearranging the stack frame such that
consecutive STG instructions reference adjacent slots (patch pending).
Reviewers: pcc, ostannard
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70286

[gn build] fix build after 22af2cbefc

[gn build] Port d3db13af7e5