[AMDGPU] Add more PAL metadata register names

Add all the registers that are currently used by
LLPC: https://github.com/GPUOpen-Drivers/llpc

This only affects disassembly of PAL metadata generated by LLPC and
similar frontends.

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

[mlir] Specify cuda-runner pass pipeline as command line options.

The cuda-runner registers two pass pipelines for nested passes,
so that we don't have to use verbose textual pass pipeline specification.

Reviewed By: herhut

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

[AMDGPU] Update s_sendmsg messages

Update the list of s_sendmsg messages known to the assembler and
disassembler and validate the ones that were added or removed in gfx9
and gfx10.

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

[lldb][NFC] Move trivial ValueObject getters/setters to the header

NFC refactoring that moves the definitions of all the trivial getters/setters to the header file
which is what we usually do in LLVM.

Reviewed By: #lldb, JDevlieghere

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

[lldb][NFC] Rename the second ValueObjectManager to ValueObjectUpdater and remove the dead code

`ValueObject.h` contains the `ValueObject::ValueObjectManager` type which is
just a typedef for the ClusterManager that takes care of the whole ValueObject
memory management. However, there is also `ValueObjectManager` defined in the
same header which is only used in the curses UI implementation and consists
mostly of dead and completely untested code.

This code been around since a while (it was added in 2016 as
8369b28da0750129ababae357bea98940800a0e0), so I think we shouldn't just revert
the whole patch.

Instead this patch just moves the class to its own header that it isn't just
hiding in the ValueObject header and renames it to `ValueObjectUpdater` that it
at least has a unique name (which I hope also slightly better reflects the
purpose of this class). I also deleted all the dead code branches and functions.

Reviewed By: #lldb, mib, JDevlieghere

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

[OpenCL] Allow taking address of functions as an extension.

When '__cl_clang_function_pointers' extension is enabled
the parser should allow obtaining the function address.

This fixes PR49264!

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

[lldb] Add asserts that prevent construction of cycles in the decl origin tracking

LLDB tracks where any imported `clang::Decl` originally came from via a simple
map from 'imported decl' to 'original decl'. That information is used to later
complete parts of the Decl when more information is requested about a certain
Decl (e.g., via the ExternalASTSource interface from Clang).

When finding the 'original decl' for a given decl, the ASTImporterDelegate
essentially just recursively follows the previously mentioned map from
'imported' to 'original decl' until it can find any further 'original decl'. The
final found decl is then the one that will be imported. The recursion is
necessary as in LLDB we don't just import decls from one ASTContext to another,
but also from one ASTContext to another via a (potentially temporary)
ASTContext. For example, the expression parser creates a temporary ASTContext
for parsing the current expression.

The problem with the recursion is however that if we somehow get a cycle into
our mapping, then the ASTImporterDelegate will just infinite recurse. As the
infinite recursion usually happens after the cycle was already created in a code
path such as completing a type, the crash backtraces we get for these bugs are
not very useful. However having the backtrace where the faulty map entry is
created usually makes the code trivial to fix (as there should be some rogue
CopyType call or something similar nearby. See for example D96366).

This patch tries to make these issues easier to track down by putting a bunch of
sanity asserts in the code that fills out the map. All the asserts are just
checking that there is no direct cycle (ASTContext maps to itself) when updating
the origin tracking map.

The assert in the ASTImportDelegate constructor is an `lldbassert` (which also
is getting checked in release builds with disabled asserts) as the code path
there is pretty cold and we can reliably detect a rogue CopyType call from
there.

I also had to update some code in
`ClangASTImporter::ASTImporterDelegate::Imported`. This code already had a
safety check for creating a cycle in the origin tracking map, but it still
constructed an ASTImporter while checking for the cycle (by requesting a
delegate via `GetDelegate` and passing two identical ASTContexts which looks
like a rogue CopyType call to the checks).

Reviewed By: shafik

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

[ValueTracking] ComputeKnownBits - minimum leading/trailing zero bits in LSHR/SHL (PR44526)

Followup to D72573 - as detailed in https://blog.regehr.org/archives/1709 we don't make use of the known leading/trailing zeros for shifted values in cases where we don't know the shift amount value.

Stop ValueTracking returning zero for poison shift patterns and use the KnownBits shift helpers directly.

Extend KnownBits::shl to combine all possible shifted combinations if both min/max shift amount values are in range.

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

[asan] Avoid putting globals in a comdat section when targetting elf.

Putting globals in a comdat for dead-stripping changes the semantic and
can potentially cause false negative odr violations at link time.
If odr indicators are used, we keep the comdat sections, as link time
odr violations will be dectected for the odr indicator symbols.

This fixes PR 47925

[Utils] collectBitParts - add truncate() handling

[docs][JITLink] Remove the JITLink doc for now.

I'll reinstate and continue investigation tomorrow.

[docs][JITLink] Yet more experiments to try to understand sphinx error.

[docs][JITLink] More experiments to try to understand sphinx error.

[dexter] Force dexter tests to use the host triple

If the default target and host triple don't match then print the following
message when the lit test runs:

    Forcing dexter tests to use host triple {HOST_TRIPLE}.

If we can't target the host arch then, when lit runs, we mark
the dexter test directories as UNSUPPORTED and print the message:

    Host triple {HOST_TRIPLE} not supported. Skipping dexter tests in
    the debuginfo-tests project.

Reviewed By: rnk

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

[clangd] Fix a race

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

[DAG] Add basic mul-with-overflow constant folding support

As noticed on D97160

[docs][JITLink] Make ``ObjectLinkingLayer`` not a paragraph start.

More experiments as I try to placate sphinx.

[docs][JITLink] Return to `` for inline literals.

Also awkwardly reformat text to test whether the error is occurring
on the line with the '::', or the previous one.

[docs][JITLink] Try explicit literal blocks for monospace list elements.

[docs][JITLink] More attempted fixes for formatting issues in the JITLink doc.

Try using the literal domain for `ObjectLinkingLayer::Plugin` and literal
blocks for multi-line method names.

Recommit "[LV] Allow tryToCreateWidenRecipe to return a VPValue, use for blends."

This reverts the revert commit 437f0bbcd509d0ed71b91ec1f86f48c2f4aae980.

It adds a new toVPRecipeResult, which forces VPRecipeOrVPValueTy to be
constructed with a VPRecipeBase *. This should address ambiguous
constructor issues for recipe sub-types that also inherit from VPValue.

[mlir][linalg] Fix Linalg roundtrip test.

The test did not check whether the operations can be parsed again after
printing them once.

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

Update REQUIRES line in 4 tests that attempt to use arm64 which should be aarch64 not arm.

[docs][JITLink] Sphinx does not like '::' in monotype. Try using a
cpp domain expr instead.

[docs][JITLink] Add a JITLink design and API document.

[JITLink] Add assertions, fix a comment.

The new assertions check that Addressables removed when removing
external or absolute symbols are not referenced by another symbol.

A comment on post-fixup passes is updated: vmaddrs have all been
set up by the time the pre-fixup passes are run, post-fixup passes
run after fixups have been applied to content.

[JITLink] Fix comments about JITLink's generic link algorithm.

These comments had gotten out of date with the code.

[AArch64] Use CMTST for != 0 vector compares (vnot (CMEQz A)).

(CMTST A, A) will only set elements to 0 if the element is 0 in A. Use
it for != 0 compares, which currently use (vnot (CMEQz A)). This saves a
mvn instruction.

Reviewed By: dmgreen

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

[OpenCL] Add ndrange builtin functions to TableGen

Also ensure all kernel enqueue functions have CL 2.0 as minimum
version.

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

[OpenCL] Add declarations with enum/typedef args

Add the remaining missing builtin function declarations that have enum
or typedef argument or return types.

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

[libcxx] [test] Don't pass INCLUDE to clang via -isystem

Passing the MSVC include dirs via -isystem makes them included before
clang's own include resource dir (<prefix>/lib/clang/<version>/include).
This causes includes of stddef.h to bypass clang's stddef.h which
defines max_align_t, which libc++ needs defined.

This was added in 4372f06d0fcaba1a6913e2f37be064e06a7b5b5b when the
initial windows testing support was added, and has been brought along
since. It's unclear if this was needed back then - now it no longer is
needed at least, and since libc++ started depending on max_align_t, this
became an issue.

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

[LLD] [COFF] Allow invoking lib.exe mode via -lib in addition to /lib

Remove a stray -lib argument in guardcf-lto.ll; llvm-lib doesn't
support generating import libs from a def file unlike lib.exe.
Previously this worked because the -lib argument was ignored
(printing only a warning).

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

[ARM] Expand the range of allowed post-incs in load/store optimizer

Currently the load/store optimizer will only fold in increments of the
same size as the load/store. This patch expands that to any legal
immediate for the post-inc instruction.

This is a recommit of 3b34b06fc5908b with correctness fixes and extra
tests.

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

Revert "[InstrProfiling] Use nobits as __llvm_prf_cnts section type in ELF"

This reverts commit 6b286d93f7ec8518c685a302269e44b06a0a24f3 because
in some cases when the optimizer evaluates the global initializer,
__llvm_prf_cnts may not be entirely zero initialized.

[libc++] [docs] [C++2b] Update status page with papers adopted in February 2021 virtual meeting.

Add REQUIRES aarch64 to test incompatible-arch.s since it fails if that target is not built.

This should fix the PS4 linux buildbot failure: http://lab.llvm.org:8011/#/builders/139/builds/63

[LegalizeIntegerTypes] Use GetExpandedInteger instead of SplitInteger in ExpandIntRes_XMULO.

We know the input is going to be expanded as well, so we should
just ask for the already expanded operands. Otherwise we create
nodes that are just going to need to be legalized.

[Test][AArch64] Test SADDO/SSUBO narrowing legalization

Reviewed By: aemerson

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

[asan] Increase CHECK limit in __sanitizer_annotate_contiguous_container

Asan allocator already support up to (1 << 40) bytes allocations.

[ThinLTO, NewPM] Run OptimizerLastEPCallbacks from buildThinLTOPreLinkDefaultPipeline

-O1 and above do dont call real optimizer pipeline in ThinLTO PreLink.
Also clang can't add PostLink OptimizerLastEPCallbacks for in-process ThinLTO.
This results in missing sanitizer passes with ThinLTO.

Simple working solution is just call OptimizerLastEPCallbacks
at the end of buildThinLTOPreLinkDefaultPipeline.

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

Reduce the number of attributes attached to each function

Patch takes advantage of the implicit default behavior to reduce the number of attributes, which in turns reduces compilation time.

Reviewed By: serge-sans-paille

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

Revert "patch" it wass my mistake inusing git

This reverts commit 3f30cd73795d17f071cc03926fea28943c65f05f.

[libc][NFC] Merge llvmlibc and llvmlibm targets in to a single target.

The single target is called llvmlibc. We can add back smaller libm and
other targets in future if required.

[Docs] Mention clone depth feature of git in LLVM getting started

The current size of the llvm-project repository exceeds 1 GB. A shallow clone can save a lot of space and time. Some developers might not aware of this feature.

Reviewed By: awarzynski

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

patch

[ASan] Introduce a way set different ways of emitting module destructors.

Previously there was no way to control how module destructors were emitted
by `ModuleAddressSanitizerPass`. However, we want language frontends (e.g. Clang)
to be able to decide how to emit these destructors (if at all).

This patch introduces the `AsanDtorKind` enum that represents the different ways
destructors can be emitted. There are currently only two valid ways to emit destructors.

* `Global` - Use `llvm.global_dtors`. This was the previous behavior and is the default.
* `None`   - Do not emit module destructors.

The `ModuleAddressSanitizerPass` and the various wrappers around it have been updated
to take the `AsanDtorKind` as an argument.

The `-asan-destructor-kind=` command line argument has been introduced to make this
easy to test from `opt`. If this argument is specified it overrides the value passed
to the `ModuleAddressSanitizerPass` constructor.

Note that `AsanDtorKind` is not `bool` because we will introduce a new way to
emit destructors in a subsequent patch.

Note that `AsanDtorKind` is given its own header file because if it is declared
in `Transforms/Instrumentation/AddressSanitizer.h` it leads to compile error
(Module is ambiguous) when trying to use it in
`clang/Basic/CodeGenOptions.def`.

rdar://71609176

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

[HIP] Fix managed variable linkage

Currently managed variables are emitted as undefined symbols, which
causes difficulty for diagnosing undefined symbols for non-managed
variables.

This patch transforms managed variables in device compilation so that
they can be emitted as normal variables.

Reviewed by: Artem Belevich

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

[AArch64][GlobalISel][PostSelectOpt] Constrain reg operands after mutating instructions.

The non-flag setting variants of instructions may have different regclass
requirements. If so, we need to constrain them.

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

[XCOFF] add C_FILE symbol at index 0 of symbol table.

This is for XCOFF DWARF support.

Seems when DWARF debug is enable, symbol 0 has special usage
for AIX binder. At least, symbol 0 can not be the .text
section. Otherwise, we get some binding time error.

Add correct C_FILE symbol at index 0 here to make AIX binder
work.

Reviewed By: hubert.reinterpretcast

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

Revert "Add more historic DWARF vendor extensions"

This reverts commit c4a91444689455a35db1e7f50bcd876a3eb86126.
Breaks check-llvm everywhere, see https://reviews.llvm.org/D97242#2583716

[lld-macho] Better deduplication of personality pointers

{D95809} introduced a mechanism for synthetic symbol creation of personality
pointers. When multiple section relocations referred to the same personality
pointer, it would deduplicate them. However, it neglected to consider that we
could have symbol relocations that also refer to the same personality pointer.
This diff fixes it.

In practice, this mix of relocations arises when there is a statically-linked
personality routine that is referenced from multiple object files. Within the
same object file, it will be referred to via section relocations, but
(obviously) other object files will refer to it via symbol relocations. Failing
to deduplicate these references resulted in us going over the
3-personality-pointer limit when linking some larger applications.

Fixes llvm.org/PR48389.

Reviewed By: #lld-macho, thakis, alexshap

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

[lld-macho] Check for arch compatibility when loading ObjFiles and TBDs

The silent failures had confused me a few times.

I haven't added a similar check for platform yet as we don't yet have logic to
infer the platform automatically, and so adding that check would require
updating dozens of test files.

Reviewed By: #lld-macho, thakis, alexshap

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

[lld-macho] Fix semantics & add tests for ARM64 GOT/TLV relocs

I've adjusted the RelocAttrBits to better fit the semantics of
the relocations. In particular:

1. *_UNSIGNED relocations are no longer marked with the `TLV` bit, even
   though they can occur within TLV sections. Instead the `TLV` bit is
   reserved for relocations that can reference thread-local symbols, and
   *_UNSIGNED relocations have their own `UNSIGNED` bit. The previous
   implementation caused TLV and regular UNSIGNED semantics to be
   conflated, resulting in rebase opcodes being incorrectly emitted for TLV
   relocations.

2. I've added a new `POINTER` bit to denote non-relaxable GOT
   relocations. This distinction isn't important on x86 -- the GOT
   relocations there are either relaxable or non-relaxable loads -- but
   arm64 has `GOT_LOAD_PAGE21` which loads the page that the referent
   symbol is in (regardless of whether the symbol ends up in the GOT). This
   relocation must reference a GOT symbol (so must have the `GOT` bit set)
   but isn't itself relaxable (so must not have the `LOAD` bit). The
   `POINTER` bit is used for relocations that *must* reference a GOT
   slot.

3. A similar situation occurs for TLV relocations.

4. ld64 supports both a pcrel and an absolute version of
   ARM64_RELOC_POINTER_TO_GOT. But the semantics of the absolute version
   are pretty weird -- it results in the value of the GOT slot being
   written, rather than the address. (That means a reference to a
   dynamically-bound slot will result in zeroes being written.) The
   programs I've tried linking don't use this form of the relocation, so
   I've dropped our partial support for it by removing the relevant
   RelocAttrBits.

Reviewed By: alexshap

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

[lld-macho] Use full input file name in invalid relocation error message

Just something I noticed while debugging arm relocations...

Reviewed By: #lld-macho, thakis

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

[mlir][Inliner] Don't optimize callees in async mode if there is only one to optimize

This avoids unnecessary async overhead in situations that won't benefit from it.

[Debug-Info][NFC] move emitDwarfUnitLength to MCStreamer class

We may need to do some customization for DWARF unit length in DWARF
section headers for some targets for some code generation path.

For example, for XCOFF in assembly path, AIX assembler does not require
the debug section containing its debug unit length in the header.

Move emitDwarfUnitLength to MCStreamer class so that we can do
customization in different Streamers

Reviewed By: ikudrin

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

Add more historic DWARF vendor extensions

The maintainer of libdwarf kindly provided this patch with a bunch of
historic DWARF extensions that are missing from Dwarf.def. This list
is helpful to avoid potential conflicts in the user-defined vendor
extension space in the future.

Patch by David Anderson!

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

[LoopNest] Use `getUniqueSuccessor()` instead when checking empty blocks

Blocks that contain only a single branch instruction to the next block can be skipped in analyzing the loop-nest structure.
This is currently done by `getSingleSuccessor()`.
However, the branch instruction might have multiple targets which happen to all be the same.
In this case, the block should still be considered as empty and skipped.

An example is `test/Transforms/LoopInterchange/update-condbranch-duplicate-successors.ll` (the LIT test for this patch is modified from it as well).

Reviewed By: Whitney

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

[SimplifyCFG] Update passingValueIsAlwaysUndefined to check more attributes

This is a simple patch to update SimplifyCFG's passingValueIsAlwaysUndefined to inspect more attributes.

A new function `CallBase::isPassingUndefUB` checks attributes that imply noundef.

Reviewed By: spatel

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

Revert "[Driver][Windows] Support per-target runtimes dir layout for profile instr generate"

This reverts commit 7f9d5d6e444c91ce6f2e377b312ac573dfc6779a.
Breaks check-clang everywhere, see https://reviews.llvm.org/D96638#2583608

[mlir] ExecutionEngine needs special handling for COFF binaries

Reviewed By: mehdi_amini

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

[mlir][Inliner] Keep the number of async pass managers constant

This prevents a bug in the pass instrumentation implementation where the main thread would end up with a different pass manager in different runs of the pass.

[NFC] Make TrailingObjects non-copyable/non-movable

This got me pretty recently... TrailingObjects cannot be copied or
moved, since they need to be pre-allocated. This patch deletes the copy
and move operations (plus re-adds the default ctor).

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

[AArch64][GlobalISel] Correct function evaluation order in applyINS

The order in which the nested calls to Builder.buildWhatever are
evaluated in differs between GCC and Clang.

This caused a bot failure because the MIR in the testcase was
coming out in a different order than expected.

Rather than using nested calls, pull them out in order to fix the
order of evaluation.

collectUsedGlobalVariables: migrate SmallPtrSetImpl overload to SmallVecImpl overload after D97128

And delete the SmallPtrSetImpl overload.

While here, decrease inline element counts from 8 to 4. See D97128 for the choice.

Reviewed By: tejohnson

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

Fix unstable SmallPtrSet iteration issues due to collectUsedGlobalVariables

While here, decrease inline element counts from 8 to 4. See D97128 for the choice.

Depends on D97128 (which added a new SmallVecImpl overload for collectUsedGlobalVariables).

Reviewed By: tejohnson

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

[ThinLTO] Make cloneUsedGlobalVariables deterministic

Iterating on `SmallPtrSet<GlobalValue *, 8>` with more than 8 elements
is not deterministic. Use a SmallVector instead because `Used` is guaranteed to contain unique elements.

While here, decrease inline element counts from 8 to 4. The number of
`llvm.used`/`llvm.compiler.used` elements is usually 0 or 1. For full
LTO/hybrid LTO, the number may be large, so we need to be careful.

According to tejohnson's analysis https://reviews.llvm.org/D97128#2582399 , 4 is
good for a large project with WholeProgramDevirt, when available_externally
vtables are placed in the llvm.compiler.used set.

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

[WPD] Fix handling of pure virtual base class

The fix in 3c4c205060c9398da705eb71b63ddd8a04999de9 caused an assert in
the case of a pure virtual base class. In that case, the vTableFuncs
list on the summary will be empty, so we were hitting the new assert
that the linkage type was not available_externally.

In the case of pure virtual, we do not want to assert, and additionally
need to set VS so that we don't treat it conservatively and quit the
analysis of the type id early.

This exposed a pre-existing issue where we were not updating the vcall
visibility on pure virtual functions when whole program visibility was
specified. We were skipping updating the visibility on any global vars
that didn't have any vTableFuncs, which meant all pure virtual were not
updated, and the later analysis would block any devirtualization of
calls that had a type id used on those pure virtual vtables (see the
handling in the other code modified in this patch). Simply remove that
check. It will mean that we may update the vcall visibility on global
vars that aren't vtables, but that setting is ignored for any global
vars that didn't have type metadata anyway.

Added a new test case that asserted without removing the assert, and
that requires the other fixes in this patch (updateVCallVisibilityInIndex
and not skipping all vtables without virtual funcs) to get a successful
devirtualization with index-only WPD. I added cases to test hybrid and
regular LTO for completeness, although those already worked without the
fixes here.

With this final fix, a clang multistage bootstrap with WPD builds and
runs all tests successfully.

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

[RISCV] Add vadd with mask and without mask builtin.

Demonstrate how to add RISC-V V builtins and lower them to IR intrinsics for V extension.

Authored-by: Roger Ferrer Ibanez <rofirrim@gmail.com>
Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com>
Differential Revision: https://reviews.llvm.org/D93446

[libc] Add a standalone flavor of an equivalent of std::string_view.

This class is to serve as a replacement for llvm::StringRef as part of
the plans to limit dependency on other parts of LLVM. One use of
llvm::StringRef in MPFRWrapper has been replaced with the new class.

Reviewed By: lntue

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

[libc] Add exhaustive test for sqrtf.

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

[dfsan] Update memset and dfsan_(set|add)_label with origin tracking

This is a part of https://reviews.llvm.org/D95835.

Reviewed-by: morehouse
Differential Revision: https://reviews.llvm.org/D97302

[LTO] Fix test failures caused by 6da7d3141651

Adds "REQUIRES: asserts", since the test uses debug messages

[WebAssembly] Fix incorrect grouping and sorting of exceptions

This CL is not big but contains changes that span multiple analyses and
passes. This description is very long because it tries to explain basics
on what each pass/analysis does and why we need this change on top of
that. Please feel free to skip parts that are not necessary for your
understanding.

---

`WasmEHFuncInfo` contains the mapping of <EH pad, the EH pad's next
unwind destination>. The value (unwind dest) here is where an exception
should end up when it is not caught by the key (EH pad). We record this
info in WasmEHPrepare to fix catch mismatches, because the CFG itself
does not have this info. A CFG only contains BBs and
predecessor-successor relationship between them, but in `WasmEHFuncInfo`
the unwind destination BB is not necessarily a successor or the key EH
pad BB. Their relationship can be intuitively explained by this C++ code
snippet:
```
try {
  try {
    foo();
  } catch (int) { // EH pad
    ...
  }
} catch (...) {   // unwind destination
}
```
So when `foo()` throws, it goes to `catch (int)` first. But if it is not
caught by it, it ends up in the next unwind destination `catch (...)`.
This unwind destination is what you see in `catchswitch`'s
`unwind label %bb` part.

---

`WebAssemblyExceptionInfo` groups exceptions so that they can be sorted
continuously together in CFGSort, as we do for loops. What this analysis
does is very simple: it creates a single `WebAssemblyException` per EH
pad, and all BBs that are dominated by that EH pad are included in this
exception. We also identify subexception relationship in this way: if
EHPad A domiantes EHPad B, EHPad B's exception is a subexception of
EHPad A's exception.

This simple rule turns out to be incorrect in some cases. In
`WasmEHFuncInfo`, if EHPad A's unwind destination is EHPad B, it means
semantically EHPad B should not be included in EHPad A's exception,
because it does not make sense to rethrow/delegate to an inner scope.
This is what happened in CFGStackify as a result of this:
```
try
  try
  catch
    ...   <- %dest_bb is among here!
  end
delegate %dest_bb
```

So this patch adds a phase in `WebAssemblyExceptionInfo::recalculate` to
make sure excptions' unwind destinations are not subexceptions of
their unwind sources in `WasmEHFuncInfo`.

But this alone does not prevent `dest_bb` in the example above from
being sorted within the inner `catch`'s exception, even if its exception
is not a subexception of that `catch`'s exception anymore, because of
how CFGSort works, which will be explained below.

---

CFGSort places BBs within the same `SortRegion` (loop or exception)
continuously together so they can be demarcated with `loop`-`end_loop`
or `catch`-`end_try` in CFGStackify.

`SortRegion` is a wrapper for one of `MachineLoop` or
`WebAssemblyException`. `SortRegionInfo` already does some complicated
things because there discrepancies between those two data structures.
`WebAssemblyException` is what we control, and it is defined as an EH
pad as its header and BBs dominated by the header as its BBs (with a
newly added exception of unwind destinations explained in the previous
paragraph). But `MachineLoop` is an LLVM data structure and uses the
standard loop detection algorithm. So by the algorithm, BBs that are 1.
dominated by the loop header and 2. have a path back to its header.
Because of the second condition, many BBs that are dominated by the loop
header are not included in the loop. So BBs that contain `return` or
branches to outside of the loop are not technically included in
`MachineLoop`, but they can be sorted together with the loop with no
problem.

Maybe to relax the condition, in CFGSort, when we are in a `SortRegion`
we allow sorting of not only BBs that belong to the current innermost
region but also BBs that are by the current region header.
(This was written this way from the first version written by Dan, when
only loops existed.) But now, we have cases in exceptions when EHPad B
is the unwind destination for EHPad A, even if EHPad B is dominated by
EHPad A it should not be included in EHPad A's exception, and should not
be sorted within EHPad A.

One way to make things work, at least correctly, is change `dominates`
condition to `contains` condition for `SortRegion` when sorting BBs, but
this will change compilation results for existing non-EH code and I
can't be sure it will not degrade performance or code size. I think it
will degrade performance because it will force many BBs dominated by a
loop, which don't have the path back to the header, to be placed after
the loop and it will likely to create more branches and blocks.

So this does a little hacky check when adding BBs to `Preferred` list:
(`Preferred` list is a ready list. CFGSort maintains ready list in two
priority queues: `Preferred` and `Ready`. I'm not very sure why, but it
was written that way from the beginning. BBs are first added to
`Preferred` list and then some of them are pushed to `Ready` list, so
here we only need to guard condition for `Preferred` list.)

When adding a BB to `Preferred` list, we check if that BB is an unwind
destination of another BB. To do this, this adds the reverse mapping,
`UnwindDestToSrc`, and getter methods to `WasmEHFuncInfo`. And if the BB
is an unwind destination, it checks if the current stack of regions
(`Entries`) contains its source BB by traversing the stack backwards. If
we find its unwind source in there, we add the BB to its `Deferred`
list, to make sure that unwind destination BB is added to `Preferred`
list only after that region with the unwind source BB is sorted and
popped from the stack.

---

This does not contain a new test that crashes because of this bug, but
this fix changes the result for one of existing test case. This test
case didn't crash because it fortunately didn't contain `delegate` to
the incorrectly placed unwind destination BB.

Fixes https://github.com/emscripten-core/emscripten/issues/13514.

Reviewed By: dschuff, tlively

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

[scan-build-py] Add sarif-html support in scan-build-py

Update scan-build-py to be able to trigger sarif-html output format in clang static analyzer.

NOTE: testcase `test_sarif_and_html_creates_sarif_and_html_reports` will fail if the default clang does not have change https://reviews.llvm.org/D96389 . This can be remediated by pointing the default clang in arguments.py to a locally built clang. I was unable to figure out where these particular tests for scan-build-py are being invoked (aside from manually), so any help there would be greatly appreciated.

Reviewed By: aabbaabb, xazax.hun

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

Fix a range-loop-analysis warning.

[WebAssembly] Disable wasm.lsda() optimization in WasmEHPrepare

In every catchpad except `catch (...)`, we add a call to
`_Unwind_CallPersonality`, which is a wapper to call the personality
function. (In most of other Itanium-based architectures the call is done
from libunwind, but in wasm we don't have the control over the VM.)
Because the personatlity function is called to figure out whether the
current exception is a type we should catch, such as `int` or
`SomeClass&`, `catch (...)` does not need the personality function call.
For the same reason, all cleanuppads don't need it.

When we call `_Unwind_CallPersonality`, we store some necessary info in
a data structure called `__wasm_lpad_context` of type
`_Unwind_LandingPadContext`, which is defined  in the wasm's port of
libunwind in Emscripten. Also the personality wrapper function returns
some info (selector and the caught pointer) in that data structure, so
it is used as a medium for communication.

One of the info we need to store is the address for LSDA info for the
current function. `wasm.lsda()` intrinsic returns that address. (This
intrinsic will be lowered to a symbol that points to the LSDA address.)
The simpliest thing is call `wasm.lsda()` every time we need to call
`_Unwind_CallPersonality` and store that info in `__wasm_lpad_context`
data structure. But we tried to be better than that (D77423 and some
more previous CLs), so if catchpad A dominates catchpad B and catchpad A
is not `catch (...)`, we didn't insert `wasm.lsda()` call in catchpad B,
thinking that the LSDA address is the same for a single function and we
already visited catchpad A and `__wasm_lpad_context.lsda` field would
already have that value.

But this can be incorrect if there is a call to another function, which
also can have the personality function and LSDA, between catchpad A and
catchpad B, because `__wasm_lpad_context` is a globally defined
structure and the callee function will overwrite its `lsda` field.

So in this CL we don't try to do any optimizaions on adding
`wasm.lsda()` call; we store the result of `wasm.lsda()` every time we
call `_Unwind_CallPersonality`. We can do some complicated analysis,
like checking if there is a function call between the dominating
catchpad and the current catchpad, but at this time it seems overkill.

This deletes three tests because they all tested `wasm.ldsa()` call
optimization.

Fixes https://github.com/emscripten-core/emscripten/issues/13548.

Reviewed By: tlively

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

[mlir][Inliner] Use llvm::parallelForEach instead of llvm::parallelTransformReduce

llvm::parallelTransformReduce does not schedule work on the caller thread, which becomes very costly for
the inliner where a majority of SCCs are small, often ~1 element. The switch to llvm::parallelForEach solves this,
and also aligns the implementation with the PassManager (which realistically should share the same implementation).

This change dropped compile time on an internal benchmark by ~1(25%) second.

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

[mlir] Refactor InterfaceMap to use a sorted vector of interfaces, as opposed to a DenseMap

A majority of operations have a very small number of interfaces, which means that the cost of using a hash map is generally larger for interface lookups than just a binary search. In the future when there are a number of operations with large amounts of interfaces, we can switch to a hybrid approach that optimizes lookups based on the number of interfaces. For now, however, a binary search is the best approach.

This dropped compile time on a largish TF MLIR module by 20%(half a second).

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

[ARM] Mir test for pre/postinc ldstopt combines. NFC

AMDGPU: Use aligned vgprs/agprs in gfx90a mir tests

These would fail a verifier check in a future change.

[SEMA] Added warn_decl_shadow support for structured bindings

https://bugs.llvm.org/show_bug.cgi?id=40858

CheckShadow is now called for each binding in the structured binding to make sure it does not shadow any other variable in scope. This does use a custom implementation of getShadowedDeclaration though because a BindingDecl is not a VarDecl

Added a few unit tests for this. In theory though all the other shadow unit tests should be duplicated for the structured binding variables too but whether it is probably not worth it as they use common code. The MyTuple and std interface code has been copied from live-bindings-test.cpp

Reviewed By: rsmith

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

[Driver][Windows] Support per-target runtimes dir layout for profile instr generate

When targeting a MSVC triple, --dependant-libs with the name of the clang runtime library for profiling is added to the command line args. In it's current implementations clang_rt.profile-<ARCH> is chosen as the name. When building a distribution using LLVM_ENABLE_PER_TARGET_RUNTIME_DIR this fails, due to the runtime file names not having an architecture suffix in the filename.

This patch refactors getCompilerRT and getCompilerRTBasename to always consider per-target runtime directories. getCompilerRTBasename now simply returns the filename component of the path found by getCompilerRT

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

Defer the decision whether to use the CU or TU index until after reading the unit header.

In DWARF v4 compile units go in .debug_info and type units go in
.debug_types. However, in v5 both kinds of units are in .debug_info.
Therefore we can't decide whether to use the CU or TU index just by
looking at which section we're reading from. We have to wait until we
have read the unit type from the header.

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

[mlir][sparse] incorporate vector index into address computation

When computing dense address, a vectorized index must be accounted
for properly. This bug was formerly undetected because we get 0 * prev + i
in most cases, which folds away the scalar part. Now it works for all cases.

Reviewed By: bixia

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

[flang][fir][NFC] remove dead code

Removes unused function from FatalError.h.

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

[llvm-profdata] Emit Error when Invalid MemOpSize Section is Created by llvm-profdata

Under certain (currently unknown) conditions, llvm-profdata is outputting
profiles that have two consecutive entries in the MemOPSize section for the
value 0. This causes the PGOMemOPSizeOpt pass to output an invalid switch
instruction with two cases for 0. As mentioned, we’re not quite sure what’s
causing this to happen, but this patch prevents llvm-profdata from outputting a
profile that has this problem and gives an error with a request for a
reproducible.

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

[AArch64] Introduce UDOT/SDOT DAG nodes

This is used to lower UDOT/SDOT instructions, as opposed to relying on
the intrinsic. Subsequent optimizations will be able to optimize them
more cleanly based on these nodes.

Revert "[docs][ORC] Fix section title and reference."

This reverts commit 6e1affe71c79a1cb5ea9d805ff7baae5cba59c0e, which caused an
error on the Sphinx doc bot.

[RISCV] Use a different constant in one of the smulo test cases to avoid converting the mul to an add.

Recommit "[AArch64][GlobalISel] Match G_SHUFFLE_VECTOR -> insert elt + extract elt"

Attempted fix for the added test failing.

https://lab.llvm.org/buildbot/#/builders/104/builds/2355/steps/5/logs/stdio

I can't reproduce the failure anywhere, so I'm going to guess that passing a
std::function as MatchInfo is sketchy in this context.

Switch it to a std::tuple and hope for the best.

[AArch64][GlobalISel] Lower G_USUBSAT and G_UADDSAT for scalars.

We have some missing optimization counterparts to LowerXALUO, but it's a start.

[AArch64] Regenerate check lines for neon-compare-instructions.ll.

Auto-generate tests so they can be updated more easily, e.g. for D97303.

[NFC][VPlan] Use VPUser to store block's predicate

Reviewed By: fhahn

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

[LV] Ensure fixNonInductionPHIs uses a valid insertion point.

In some cases, Builder's insertion point may be invalidated before using
it in VPTransformState::get. Make sure the insertion point is
up-to-date.

This should fix various sanitizer errors, like
https://lab.llvm.org/buildbot/#/builders/5/builds/4933/steps/9/logs/stdio

[clang-tidy] Add cppcoreguidelines-prefer-member-initializer to ReleaseNotes

Following a discussion about the current state of this check on the 12.X branch, it was decided to purge the check as it wasn't in a fit to release state, see https://llvm.org/PR49318.
This check has since had some of those issues addressed and should be good for the next release cycle now, pending any more bug reports about it.

Reviewed By: aaron.ballman

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

[InstSimplify] Handle nsw shl -> poison patterns

Pulled out from D90479 - this recognises invalid nsw shl patterns with signbit changes that result in poison.

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

[AMDGPU] Set threshold for regbanks reassign pass

This is to limit compile time. I did experiments with some
inputs and found that compile time keeps reasonable for this
pass if we have less than 100000 virtual registers and then
starts to explode somewhere between 100000 and 150000.

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

[flang][test] Share all driver test dirs between `f18` and `flang-new`

Originally, when we added the new driver, we created dedicated test
directories for `flang-new`. This way we separated the tests for the
`throwaway` and the new driver.

As we are increasing test coverage and starting to share tests between
the two drivers, it makes sense to share all directories and instead
rely on:
```
! REQUIRES: new-flang-driver
```
to mark tests as exclusively for the new driver.

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

[OpenMP][NVPTX] Fixed a compilation error in deviceRTLs caused by unsupported feature in release verion of LLVM

`ptx71` is not supported in release version of LLVM yet. As a result,
the support of CUDA 11.2 and CUDA 11.1 caused a compilation error as mentioned
in D97004. Since the support in D97004 is just a WA for releease, and we'll not
use it in the near future, using `ptx70` for CUDA 11 is feasible.

Reviewed By: jdoerfert

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