[AArch64] Identify SAD pattern

(ABS (SUB (EXTEND a), (EXTEND b))) to ZERO_EXTEND((UABD a, b))
(ABS (SUB (SIGN_EXTEND a), (SIGN_EXTEND b))) to ZERO_EXTEND((SABD a, b))

This partially solves the bug: https://bugs.llvm.org/show_bug.cgi?id=46888
Meta ticket: https://bugs.llvm.org/show_bug.cgi?id=46929

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

Revert "    Enable LSAN for Android"

Breaks android build.
asan_malloc_dispatch_k needs memalign interceptor disabled in this patch.

This reverts commit a2291a58bf1c860d026581fee6fe96019dc25440.

Revert "[VPlan] Use VPValue def for VPMemoryInstructionRecipe."

It introduced a memory leak.

This reverts commit 525b085a65d30a5f2ae2af38c0be252fe8d4781b.

[AArch64] Implement .variant_pcs directive

A dynamic linker with lazy binding support may need to handle variant
PCS function symbols specially, so an ELF symbol table marking
STO_AARCH64_VARIANT_PCS [1] was added to address this.

Function symbols that follow the vector PCS are marked via the
.variant_pcs assembler directive, which takes a single parameter
specifying the symbol name and sets the STO_AARCH64_VARIANT_PCS st_other
flag in the object file.

[1] https://github.com/ARM-software/abi-aa/blob/master/aaelf64/aaelf64.rst#st-other-values

Reviewed By: sdesmalen

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

[TableGen][SchedModels] Fix aliasing of SchedWriteVariant

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

[SVE] Add ISel patterns for "insert undef_nxv#f##, f##, 0"

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

[ARM] Follow AACPS standard for volatile bit-fields access width

This patch resumes the work of D16586.
According to the AAPCS, volatile bit-fields should
be accessed using containers of the widht of their
declarative type. In such case:
```
struct S1 {
  short a : 1;
}
```
should be accessed using load and stores of the width
(sizeof(short)), where now the compiler does only load
the minimum required width (char in this case).
However, as discussed in D16586,
that could overwrite non-volatile bit-fields, which
conflicted with C and C++ object models by creating
data race conditions that are not part of the bit-field,
e.g.
```
struct S2 {
  short a;
  int  b : 16;
}
```
Accessing `S2.b` would also access `S2.a`.

The AAPCS Release 2020Q2
(https://documentation-service.arm.com/static/5efb7fbedbdee951c1ccf186?token=)
section 8.1 Data Types, page 36, "Volatile bit-fields -
preserving number and width of container accesses" has been
updated to avoid conflict with the C++ Memory Model.
Now it reads in the note:
```
This ABI does not place any restrictions on the access widths of bit-fields where the container
overlaps with a non-bit-field member or where the container overlaps with any zero length bit-field
placed between two other bit-fields. This is because the C/C++ memory model defines these as being
separate memory locations, which can be accessed by two threads simultaneously. For this reason,
compilers must be permitted to use a narrower memory access width (including splitting the access into
multiple instructions) to avoid writing to a different memory location. For example, in
struct S { int a:24; char b; }; a write to a must not also write to the location occupied by b, this requires at least two
memory accesses in all current Arm architectures. In the same way, in struct S { int a:24; int:0; int b:8; };,
writes to a or b must not overwrite each other.
```

I've updated the patch D16586 to follow such behavior by verifying that we
only change volatile bit-field access when:
 - it won't overlap with any other non-bit-field member
 - we only access memory inside the bounds of the record
 - avoid overlapping zero-length bit-fields.

Regarding the number of memory accesses, that should be preserved, that will
be implemented by D67399.

Reviewed By: ostannard

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

[SCEV] BuildConstantFromSCEV(): properly handle SCEVSignExtend from ptr

Much similar to the ZExt/Trunc handling.
Thanks goes to Alexander Richardson for nudging towards noticing this one proactively.

The appropriate (currently crashing) test coverage added.

[AMDGPU] v_mac_legacy_f32 does not support DPP

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

Add expected response time and escalation path to the security docs

Following up on the discussion within the group during the roundtable at
the 2020 LLVM Developers Meeting, this commit adds to the security docs:

* How long we expect acknowledging security reports will take
* The escalation path the reporter can follow if they get no response

A temporary line inviting reporters to directly follow the escalation
path while the mailing list is being setup is also added.

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

[SCEV] BuildConstantFromSCEV(): properly handle SCEVZeroExtend from ptr

As being reported in https://reviews.llvm.org/D88806#2326944,
this is pretty much the sibling problem of https://reviews.llvm.org/D88806#2325340,
with root cause being that SCEV now models `ptrtoint` as trunc/zext/self of unknown.

The appropriate (currently crashing) test coverage added.

[X86] Convert integer _mm_reduce_* intrinsics to emit llvm.reduction intrinsics (PR47506)

Emit the equivalent integer reduction intrinsics in IR instead of expanding to shuffle+arithmetic sequences.

The fadd/fmul reductions might be trickier as they assume a similar bisection reduction while the generic intrinsics assume a sequential reduction (intel docs are ambiguous on the correct approach) - I'm not sure if we want to always tag them with reassoc? Anyway, that issue can wait until a separate fp patch along with the fmin/fmax reductions.

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

[InstCombine] Support uniform vector splats in ((((X >> C) & CC) + Y) << C) folds.

Add support for uniform vector splats (no undefs).

[Test] Use generated auto-checks to make further changes more visible

[AMDGPU] Use lowercase for subtarget feature names in RUN lines

[llvm-install-name-tool] Add -delete_all_rpaths option

This diff adds an option to remove all rpaths from a Mach-O binary.

Test plan: make check-all

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

[X86][SelectionDAG] Add SADDO_CARRY and SSUBO_CARRY to support multipart signed add/sub overflow legalization.

This passes existing X86 test but I'm not sure if it handles all type
legalization cases it needs to.

Alternative to D89200

Reviewed By: efriedma

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

Reland "[WebAssembly] Emulate v128.const efficiently""

This reverts commit 432e4e56d3d2, which reverted 542523a61a21. Two issues from
the original commit have been fixed. First, MSVC does not like when std::array
is initialized with only single braces, so this commit switches to using the
more portable double braces. Second, there was a subtle endianness bug that
prevented the original commit from working correctly on big-endian machines,
which has been fixed by switching to using endianness-agnostic bit twiddling
instead of type punning.

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

[lld][WebAssembly] Don't GC library objects under `--whole-archive`

Followup on https://reviews.llvm.org/D85062 which ignores
entire library objects when no symbols are used within them.
This is shouldn't apply with `--whole-archive` since this
is specified to treat them like direct object inputs.

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

[mlir] Add async.await operation to async dialect

Add async.await operation to "unwrap" async.values

Reviewed By: mehdi_amini

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

Canonicalize declaration pointers when forming APValues.

References to different declarations of the same entity aren't different
values, so shouldn't have different representations.

Recommit of e6393ee813178e9d3306b8e3c6949a4f32f8a2cb, most recently
reverted in 9a33f027ac7d73e14ae287e78ab554142d1cbc8f due to a bug caused
by ObjCInterfaceDecls not propagating availability attributes along
their redeclaration chains; that bug was fixed in
e2d4174e9c66251d1b408234b53f53d0903c0285.

Ensure that InheritedAttrs are properly inherited along a redeclaration
chain for ObjCInterfaceDecls.

Only one such declaration can actually have attributes (the definition,
if any), but generally we assume that we can look for InheritedAttrs on
the most recent declaration.

[llvm-readobj] Don't print out section names for STABS symbols

This diff is similar to what D71394 did for `llvm-objdump` -- it avoids
trying to look up a section name for STABS symbols, since some STABS
symbol types (like `N_OSO`) use the `n_sect` field to store other data
instead of a section index.

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

[WebAssembly] GC constructor functions in otherwise unused archive objects

This allows `__wasilibc_populate_libpreopen` to be GC'd in more cases
where it isn't needed, including when linked from Rust's libstd.

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

[gn build] Port 412cdcf2edf

[X86] Add HRESET instruction.

For more details about these instructions, please refer to the latest ISE document: https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-programming-reference.

Reviewed By: craig.topper

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

Add accessors. (NFC)

There's a place in swift-lldb where it is useful to create a copy of
an lldb_private::Variable. Adding these two accessors makes this
possible.

[llc] -filetype=null: don't create .null if -o is not specified

The new behavior is consistent with llvm-mc -filetype=null.

[lld][WebAssembly] Add support for -Bsymbolic flag

This flag works in a similar way to the ELF linker in that it
will resolve any defined symbols to their local definition with
a shared library or -pie executable.

This flag has no effect on static linking.

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

[AMDGPU] Update LiveVariables in convertToThreeAddress()

This can fix an asan failure like below.
==15856==ERROR: AddressSanitizer: use-after-poison on address ...
READ of size 8 at 0x6210001a3cb0 thread T0
    #0 llvm::MachineInstr::getParent()
    #1 llvm::LiveVariables::VarInfo::findKill()
    #2 TwoAddressInstructionPass::rescheduleMIBelowKill()
    #3 TwoAddressInstructionPass::tryInstructionTransform()
    #4 TwoAddressInstructionPass::runOnMachineFunction()

We need to update the Kills if we replace instructions. The Kills
may be later accessed within TwoAddressInstruction pass.

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

[llvm] Export LLVM_USE_SPLIT_DWARF in LLVMConfig.cmake

Export LLVM_USE_SPLIT_DWARF in LLVMConfig.cmake so that it can be used
from standalone builds of clang and lldb. Currently, there is no way for
standalone builds to know whether this option was set which means that
it only applies to LLVM.

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

[SemaTemplate] Stop passing insertion position around during VarTemplate instantiation

They can get stale at use time because of updates from other recursive
specializations. Instead, rely on the existence of previous declarations to add
the specialization.

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

[lldb] Remove unused code in GetVersion (NFC)

Small cleanup to `lldb_private::GetVersion()`.

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

[lldb] Handle alternative output in TestAbortExitCode

This test

On macOS, this test can instead return `status = 0 (0x00000000) Terminated due to signal 6`. This updates the `CHECK` accordingly.

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

[clangd] Try harder to get accurate ranges for documentSymbols in macros

Fixes https://github.com/clangd/clangd/issues/500

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

[lldb] Add instrumentation runtime category

[lldb] Alphabetically sort test categories (NFC)

[BitCodeAnalyzer] Add a few missing TYPE_CODES and MODULE_CODE_COMDAT to GetCodeName

Happened to notice some of these printing as UnknownCode while running llvm-bcanalyzer on a bc file I had.

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

[Coroutine] Rename coro-semmetric-transfer.cpp and possibly fix test failure

Some tests start to fail after https://reviews.llvm.org/D89066.
It's because the size of pointers are different on different targets.
Limit the target in the command so there is no confusion.
Also noticed I had typo in the test name.
Adding disable-llvm-passes option to make the test more stable as well.

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

[mlir] Make Python bindings installable.

* Links against libMLIR.so if the project is built for DYLIBs.
* Puts things in the right place in build and install time python/ trees so that RPaths line up.
* Adds install actions to install both the extension and sources.
* Copies py source files to the build directory to match (consistent layout between build/install time and one place to point a PYTHONPATH for tests and interactive use).
* Finally, "import mlir" from an installed LLVM just works.

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

[AArch64] Add tests for 128-bit shift variations.

It looks like there's still some room for optimization; the funnel shift
lowering is more efficient than the lowering of actual shifts.

Lex: Avoid MemoryBuffer* key in ExcludedPreprocessorDirectiveSkipMapping, NFC

This is a prep patch for changing SourceManager to return
`Optional<MemoryBufferRef>` instead of `MemoryBuffer`. With that change the
address of the MemoryBuffer will be gone, so instead use the start of the
buffer as the key for this map.

No functionality change intended, as it's expected that the pointer identity
matches between the buffers and the buffer data.

Radar-Id: rdar://70139990
Differential Revision: https://reviews.llvm.org/D89136

Ensure TreeTransform considers ParmVarDecls as transformed Decls

See PR47804:

TreeTransform uses TransformedLocalDecls as a map of declarations that
have been transformed already. When doing a "TransformDecl", which
happens in the cases of updating a DeclRefExpr's target, the default
implementation simply returns the already transformed declaration.

However, this was not including ParmVarDecls. SO, any use of
TreeTransform that didn't re-implement TransformDecl would NOT properly
update the target of a DeclRefExpr, resulting in odd behavior.

In the case of Typo-recovery, the result was that a lambda that used its
own parameter would cause an error, since it thought that the
ParmVarDecl referenced was a different lambda. Additionally, this caused
a problem in the AST (a declrefexpr into another scope) such that a
future instantiation would cause an assertion.

This patch ensures that the ParmVarDecl transforming process records
into TransformedLocalDecls so that the DeclRefExpr is ALSO updated.

[CostModel] get type-based cost for vector intrinsics directly

This is NFC-intended (the reductions and other intrinsics have
tests that should provide coverage) - trying to untangle the
mess that has formed here.

We were stripping the arguments off of the given
"IntrinsicCostAttributes" and then semi-recursively
calling back into getIntrinsicInstrCost() only to
then call getTypeBasedIntrinsicInstrCost(), so make
that call directly instead.

DependencyScanning: pull factory function into MinimizedVFS, NFC

Avoid need for getBufferPtr API, simplifying another patch. No
functionality change.

[TableGen] Add overload of RecordKeeper::getAllDerivedDefinitions()
  and use in PseudoLowering backend.
Now the two getAllDerivedDefinitions() use StringRef and Arrayref.
Use all_of() in getAllDerivedDefinitions().

[X86] Add more tests for D89178. NFC

[MinGW][clang-shlib] Build only when LLVM_LINK_LLVM_DYLIB is enabled

Otherwise it's easy to hit 2^16 DLL exports limit.

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

[LLD] [COFF] Fix a ubsan error in pdb-type-server-missing.yaml

This error has been present since 5519e4da83d1abc666203.

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

[libunwind] [SEH] Don't interact with foreign exceptions

This unfortunately means that we don't execute C++ destructors when
unwinding past such frames for a different SEH unwind purpose (e.g.
as part of setjmp/longjmp), but that case isn't handled properly at
the moment (the original unwind intent is lost and we end up with an
unhandled exception). This patch makes sure the foreign unwind terminates
as intended.

After executing a handler, _Unwind_Resume doesn't have access to
the target frame parameter of the original foreign unwind. We also
currently blindly set ExceptionCode to STATUS_GCC_THROW - we could
set that correctly by storing the original code in _GCC_specific_handler,
but we don't have access to the original target frame value.

This also matches what libgcc's SEH unwinding code does in this case.

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

[libomptarget][amdgcn] Implement partial barrier

[libomptarget][amdgcn] Implement partial barrier

named_sync is used to coordinate non-spmd kernels. This uses bar.sync on nvptx.
There is no corresponding ISA support on amdgcn, so this is implemented using
shared memory, one word initialized to zero.

Each wave increments the variable by one. Whichever wave is last is responsible
for resetting the variable to zero, at which point it and the others continue.

The race condition on a wave reaching the barrier before another wave has
noticed that it has been released is handled with a generation counter, packed
into the same word.

Uses a shared variable that is not needed on nvptx. Introduces a new hook,
kmpc_impl_target_init, to allow different targets to do extra initialization.

Reviewed By: jdoerfert

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

[mlir][Linalg] Temporarily circumvent TensorConstant bufferize bug

The TensorConstantOp bufferize conversion pattern has a bug that
makes it incorrect in the case of vectors whose alignment is not
the natural alignment. Circumvent it temporarily by using a power of 2.

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

[gn build] Add libclang_rt.ios.a, libclang_rt.iossim.a to the build

It's built with just-built clang, like all other compiler-rt parts
in the GN build.

This requires adding some cross build support to the mac toolchain.

Also add explicit mmacosx-version-min and miphoneos-version-min
flags to the build.

ios.a is only built with the arm64 slice, iossim.a only with the
x86_64 slice for now. (The latter should maybe become host_cpu
when Arm Macs become a common iOS development platform.)

With this, it's possible to build chromium/iOS with a GN-built LLVM.

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

[AMDGPU] Correct processor names for gfx1010 and gfx1011

Change-Id: Ie409f86876b0437d0b0405aff42872963708d926

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

Reland "[SCEV] Model ptrtoint(SCEVUnknown) cast not as unknown, but as zext/trunc/self of SCEVUnknown"

This relands commit 1c021c64caef83cccb719c9bf0a2554faa6563af which was
reverted in commit 17cec6a11a12f815052d56a17ef738cf246a2d9a because
an assertion was being triggered, since `BuildConstantFromSCEV()`
wasn't updated to handle the case where the constant we want to truncate
is actually a pointer. I was unsuccessful in coming up with a test case
where we'd end there with constant zext/sext of a pointer,
so i didn't handle those cases there until there is a test case.

Original commit message:

While we indeed can't treat them as no-ops, i believe we can/should
do better than just modelling them as `unknown`. `inttoptr` story
is complicated, but for `ptrtoint`, it seems straight-forward
to model it just as a zext-or-trunc of unknown.

This may be important now that we track towards
making inttoptr/ptrtoint casts not no-op,
and towards preventing folding them into loads/etc
(see D88979/D88789/D88788)

Reviewed By: mkazantsev

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

[NFC][ScalarEvolution] Add tests with ptrtoint in constant context in loop

Reduced from the https://reviews.llvm.org/D88806#2325340

Revert "Canonicalize declaration pointers when forming APValues."

This reverts commit 9dcd96f728863d40d6f5922ed52732fdd728fb5f.

See https://crbug.com/1134762.

[SVE] Fix VBITS_GE_256 typo in fixed-width tests.

This seems to be a typo that propagated to a number of tests. Replace VBITS_GE_256 with CHECK. There is no VBITS_GE_256.

[trace] Scaffold "thread trace dump instructions"

Depends on D88841

As per the discussion in the RFC, we'll implement both

  thread trace dump [instructions | functions]

This is the first step in implementing the "instructions" dumping command.

It includes:

- A minimal ProcessTrace plugin for representing processes from a trace file. I noticed that it was a required step to mimic how core-based processes are initialized, e.g. ProcessElfCore and ProcessMinidump. I haven't had the need to create ThreadTrace yet, though. So far HistoryThread seems good enough.
- The command handling itself in CommandObjectThread, which outputs a placeholder text instead of the actual instructions. I'll do that part in the next diff.
- Tests

{F13132325}

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

[flang][openacc] Lower data construct

This patch upstream the lowering of Data construct that was initially done in
https://github.com/flang-compiler/f18-llvm-project/pull/460.

Reviewed By: jeanPerier

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

[Coroutine][Sema] Only tighten the suspend call temp lifetime for final awaiter

In https://reviews.llvm.org/D87470 I added the change to tighten the lifetime of the expression awaiter.await_suspend().address.
Howver it was incorrect. ExprWithCleanups will call the dtor and end the lifetime for all the temps created in the current full expr.
When this is called on a normal await call, we don't want to do that.
We only want to do this for the call on the final_awaiter, to avoid writing into the frame after the frame is destroyed.
This change fixes it, by checking IsImplicit.

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

update .txt --> .md links

[mlir] fixing typo in parseAttribute that was ignoring caller-specified types

Reviewed By: rriddle

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

[LLDB] Fix 37 tests on Windows

A Windows-style LLDB_PYTHON_HOME path in a Cmake template didn't have the
backslashes escaped, which led to a garbled paths derived from it.  Fixed
by expanding the environment variable as a raw string literal.

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

[Inliner][NPM] Fix various tests under NPM

alloca-dbgdeclare-merge.ll:
alloca-merge-align.ll:
array_merge.ll:
 NPM inliner does not merge allocas

delete-call.ll:
 NPM inliner does not delete readonly calls

externally_available.ll:
 NPM inliner does not delete available_externally functions

inline-cold-callee.ll:
inline-hot-callee.ll:
 inline-hot-callee.ll has a comment saying it only applies to legacy PM,
 I assume same for inline-cold-callee.ll

devirtualize-2.ll:
inline-hot-callsite:
monster_scc.ll:
pr22285.ll:
 already has legacy and new PM RUN lines

inline-cold.ll:
 profile-summary required to see callee as cold

prof-update-sample.ll:
 profile-summary required to update branch_weights

Reviewed By: davidxl

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

[InstCombine] FoldShiftByConstant - create Scalar/Vector constant with ConstantInt::get(). NFCI.

There's no need to create constant vector splats manually - missed this one in rG24dd0cd1edd5

[clangd] Heuristic resolution for dependent type and template names

Fixes https://github.com/clangd/clangd/issues/543

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

[sanitizer] Disable fast_unwind_on_malloc as default for arm-linux-gnu

ARM thumb/thumb2 frame pointer is inconsistent on GCC and Clang [1]
and fast-unwider is also unreliable when mixing arm and thumb code [2].

The fast unwinder on ARM tries to probe and compare the frame-pointer
at different stack layout positions and it works reliable only on
systems where all the libraries were built in arm mode (either with
gcc or clang) or with clang in thmb mode (which uses the same stack
frame pointer layout in arm and thumb).

However when mixing objects built with different abi modes the
fast unwinder is still problematic as shown by the failures on the
AddressSanitizer.ThreadStackReuseTest. For these failures, the
malloc is called by the loader itself and since it has been built
with a thum enabled gcc, the stack frame is not correctly obtained
and the suppression rule is not applied (resulting in a leak warning).

The check for fast-unwinder-works is also changed: instead of checking
f it is explicit enabled in the compiler flags, it now checks if
compiler defined thumb pre-processor.

This should fix BZ#44158.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92172
[2] https://bugs.llvm.org/show_bug.cgi?id=44158

Reviewed By: eugenis

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

[X86] Support -march=x86-64-v[234]

PR47686. These micro-architecture levels are defined in the x86-64 psABI:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9

GCC 11 will support these levels.

Note, -mtune=x86-64-v[234] are invalid and __builtin_cpu_is cannot be
used on them.

Reviewed By: craig.topper, RKSimon

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

[flang][openacc] Lower parallel construct

This patch upstream the lowering of Parallel construct that was initially done in
https://github.com/flang-compiler/f18-llvm-project/pull/460.

Reviewed By: jeanPerier

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

[flang][openacc] Update Loop Construct lowering to use fir::getBase

This patch update the loop construct lowring to match fir-dev changes.

Reviewed By: jeanPerier

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

[InstCombine] FoldShiftByConstant - create Scalar/Vector constant with ConstantInt::get(). NFCI.

There's no need to create constant vector splats manually.

[InstCombine] FoldShiftByConstant - merge equivalent types. NFCI.

Consistently use the original shift instruction's Type/BitWidth instead of the operands, casted values etc.

Restore "[ThinLTO] Avoid temporaries when loading global decl attachment metadata"

This restores commit ab1b4810b55279bcf6fdd87be74a403440be3991 which was
reverted in 01b9deba76a950f04574b656c7c31ae389104f2d, with a fix for the
issue it caused. We should use a temporary BitstreamCursor when
loading the global decl attachment records so that the abbrev ids held
in the lazy loading IndexCursor are not clobbered. Enhanced the test so
that the issue is exposed there.

Original description:

When performing ThinLTO importing, the metadata loader attempts to lazy
load, by building an index. However, module level global decl attachment
metadata was being parsed early while building the index, since the
associated (module level) global values aren't materialized on demand.
This results in the creation of forward reference temporary metadatas,
which are expensive.

Normally, these module level global values don't have much attached
metadata. However, in the case of -fwhole-program-vtables (e.g. for
whole program devirtualization), the vtables may have many attached type
metadatas. This was resulting in very slow performance when performing
ThinLTO importing with the default lazy loading.

This patch restructures the handling of these global decl attachment
records, delaying their parsing until after the lazy loading index has
been built. Then the parser can use the interface that loads from the
index, which resolves forward references immediately instead of creating
expensive temporaries.

For one ThinLTO backend that imports from modules containing huge
numbers of vtables and associated types, I measured the following
compile times for the metadata materialization during function
importing, rounded to nearest second:

No -fwhole-program-vtables:
  Lazy loading on (head):  1s
  Lazy loading off (head): 3s
  Lazy loading on (patch): 1s

With -fwhole-program-vtables:
  Lazy loading on (head):  440s
  Lazy loading off (head): 4s
  Lazy loading on (patch): 2s

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

[VPlan] Use VPValue def for VPMemoryInstructionRecipe.

This patch turns VPMemoryInstructionRecipe into a VPValue and uses it
during VPlan construction and codegeneration instead of the plain IR
reference where possible.

Reviewed By: dmgreen

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

Make likelihood lit test less brittle

Jeremy Morse discovered an issue with the lit test introduced in D88363. The
test gives different results for Sony's `-O1`.

The test needs to run at `-O1` otherwise the likelihood attribute will be
ignored. Instead of running all `-O1` passes it only runs the lower-expect pass
which is needed to lower `__builtin_expect`.

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

[compiler-rt] Suppress -Wunused-result due to ::write when _FORTIFY_SOURCE>0 in glibc

Noticed by Peter Foley.
In glibc, ::write is declared as __attribute__((__warn_unused_result__)) when __USE_FORTIFY_LEVEL is larger than 0.

Revert 1c021c64c "[SCEV] Model ptrtoint(SCEVUnknown) cast not as unknown, but as zext/trunc/self of SCEVUnknown"

> While we indeed can't treat them as no-ops, i believe we can/should
> do better than just modelling them as `unknown`. `inttoptr` story
> is complicated, but for `ptrtoint`, it seems straight-forward
> to model it just as a zext-or-trunc of unknown.
>
> This may be important now that we track towards
> making inttoptr/ptrtoint casts not no-op,
> and towards preventing folding them into loads/etc
> (see D88979/D88789/D88788)
>
> Reviewed By: mkazantsev
>
> Differential Revision: https://reviews.llvm.org/D88806

It caused the following assert during Chromium builds:

  llvm/lib/IR/Constants.cpp:1868:
  static llvm::Constant *llvm::ConstantExpr::getTrunc(llvm::Constant *, llvm::Type *, bool):
  Assertion `C->getType()->isIntOrIntVectorTy() && "Trunc operand must be integer"' failed.

See code review for a link to a reproducer.

This reverts commit 1c021c64caef83cccb719c9bf0a2554faa6563af.

[GlobalISel][KnownBits] Early return on out of bound shift amounts

If the known shift amount is bigger than or equal to the bitwidth of the type of the value to be shifted,
the result is target dependent, so don't try to infer any bits.

This fixes a crash we've seen in one of our internal test suites.

Reviewed By: arsenm

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

[Tests] Regenerate test checks; NFC

[NFC][MC] Use MCRegister in LiveRangeMatrix

The change starts from LiveRangeMatrix and also checks the users of the
APIs are typed accordingly.

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

[VPlan] Use operands for printing of VPWidenMemoryInstructionRecipe.

Now that operands of the recipe are managed through VPUser, we can
simplify the printing by just using the operands.

[NFC][Regalloc] Pass VirtRegMap by reference.

It's never null - the reason it's modeled as a pointer is because the
pass can't init it in its ctor. Passing by ref simplifies the code, too,
as the null checks were unnecessary complexity.

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

[AMDGPU] Print metadata on error

If the metadata is valid yaml, we can print it, even if it failed
validation. That makes it easier to debug any wrong metadata.

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

[LoopDeletion] Remove over-eager SCEV verification.

60b852092c98dbdc6248d60109d90ae6f8ad841c introduced SCEV verification to
deleteDeadLoop, but it appears this check is currently a bit over-eager
and some users of deleteDeadLoop appear to only patch up SE after
calling it (e.g. PR47753).

Remove the extra check for now. We can consider adding it back after we
tracked down the source of the inconsistency for PR47753.

[AMDGPU] Insert waterfall loops for divergent calls

Extend loadSRsrcFromVGPR to allow moving a range of instructions into
the loop. The call instruction is surrounded by copies into physical
registers which should be part of the waterfall loop.

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

[SVE] Lower fixed length VECREDUCE_XOR operation

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

[AMDGPU] Use @LINE for error checking in gfx10 assembler tests

[InstCombine] matchFunnelShift - fold or(shl(a,x),lshr(b,sub(bw,x))) -> fshl(a,b,x) iff x < bw (REAPPLIED)

If value tracking can confirm that a shift value is less than the type bitwidth then we can more confidently fold general or(shl(a,x),lshr(b,sub(bw,x))) patterns to a funnel/rotate intrinsic pattern without causing bad codegen regressions in the backend (see D89139).

Reapplied after the shift canonicalization in rG02295e6d1a15 which removed the need to flip the shift values.

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

[InstCombine] matchFunnelShift - remove shift value commutation. NFCI.

After rG02295e6d1a15 we no longer need to invert the shift values for fshr - this is just hidden at the moment as funnel shifts only ever match for constant values so never use the fshr "Sub on SHL" path.

[InstCombine] matchFunnelShift - canonicalize to OR(SHL,LSHR). NFCI.

Simplify the shift amount matching code by canonicalizing the shift ops first.

[lldb] Note difference in vFile:pread/pwrite format for lldb

https://sourceware.org/gdb/current/onlinedocs/gdb/Host-I_002fO-Packets.html

States that all numbers should be hexidecimal but lldb
uses decimals in vFile:pread and vFile:pwrite.

lldb-server can accept either since it ends up using
strtoull which will detect the base being used.

Reviewed By: labath

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

[clangd] Disable a failure TopLevelDecls test.

The test fails on clang-ppc64le-rhel buildbot, needs further
investigation.

Dump decl when the test matcher fails.

[NFC] Remove redundant isFullSet checks

Full set case is handled inside intersection, no need to
litter the code with duplicating them outside.

[gn build] Port f9317f7bf6b

[clangd] Record memory usages after each notification

Depends on D88415

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

[clangd] Add a helper for exposing tracer status

[clangd] Introduce memory usage dumping to TUScheduler, for Preambles and ASTCache

File-granular information is considered details.

Depends on D88411

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

[clangd] Introduce memory dumping to FileIndex, FileSymbols and BackgroundIndex

File-granular information is considered details.

Depends on D88411

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