…05549)

Fix SIInsertWaitcnts to account for this by adding extra waits to avoid
WAW dependencies.

…lvm#83807)

This fixes an odd problem with the regex when `CMAKE_INSTALL_LIBDIR` is
not defined:

`string sub-command REGEX, mode REPLACE: regex "$" matched an empty
string.`

Fixes llvm#83802

…eclare} (llvm#105570)

Constify debug DbgVariableRecord::{isDbgValue,isDbgDeclare}.

This reverts commit 6528157.

I'm reverting llvm#104523
(llvm@f01f80c)
and this fixup belongs to the same series of changes.

This reverts commit 6f45602, which
depends on llvm#104523, which I'm
reverting.

llvm#104523)"

This reverts commit f01f80c.

This commit introduces an msan violation. See the discussion on llvm#104523.

Discard the subexpr.

…#105544)

- Refactor SetTheory code to use const pointers when possible.
- Use auto for variables initialized using dyn_cast<>.
- Use range based for loops and early continue.

There was a duplicate link target.

This region is intended to separate alloca operations from reduction
variable initialization. This makes it easier to hoist allocas to the
entry block before control flow and complex code for initialization.

The verifier checks that there is at most one block in the alloc region.
This is not sufficient to avoid control flow in general MLIR, but by the
time we are converting to LLVMIR structured control flow should already
have been lowered to the cf dialect.

1/3
Part 2: llvm#102524
Part 3: llvm#102525

The intention of this change is to ensure that allocas end up in the
entry block not spread out amongst complex reduction variable
initialization code.

The tests we have are quite minimized for readability and
maintainability, making the benefits less obvious. The use case for this
is when there are multiple reduction variables each will multiple blocks
inside of the init region for that reduction.

2/3
Part 1: llvm#102522
Part 3: llvm#102525

I removed the `*-hlfir*` tests because they are duplicate now that the
other tests have been updated to use the HLFIR lowering.

3/3
Part 1: llvm#102522
Part 2: llvm#102524

Proof: https://alive2.llvm.org/ce/z/v6VtXz

…finitions and partial specializations (llvm#104030)

We need to rebuild the template parameters of out-of-line
definitions/specializations of member templates in the context of the
current instantiation for the purposes of declaration matching. We
already do this for function templates and class templates, but not
variable templates, partial specializations of variable template, and
partial specializations of class templates. This patch fixes the latter
cases.

)

Convert them to Pointers, do the offset calculation and then convert
them back to function pointers.

Tests for cases that would have been regressed by
llvm#104941.

…105644)

This can be handled in ODS instead of writing custom parsing/printing
code.

Thanks for the idea @skatrak

…vm#102752)

Currently `mlir.llvm.constant` of structure types restricts that the
structure type effectively represents a complex type -- it must have
exactly two fields of the same type and the field type must be either an
integer type or a float type.

This PR relaxes this restriction and it allows the structure type to
have an arbitrary number of fields.

…ble objects (llvm#104778)

Whilst dealing with review comments on

llvm#96752

I discovered that SCEV does not know about the dereferenceable attribute
on function arguments so I have updated getRangeRef to make use of it
by calling getPointerDereferenceableBytes.

These builtins are currently returning CR0 which will have the format
[0, 0, flag_true_if_saved, XER].
We only want to return flag_true_if_saved. This patch adds a shift to
remove the XER bit before returning.

This aligns the transform with what foldLogOpOfMaskedICmp() does.

- Landing page: add link to the libc++ Discord channel
- Landing page: reorder "Getting Involved" above "Design documents"
- Landing page: remove "Notes and Known Issues" which was completely outdated
- Rename "Using Libc++" to "User Documentation" and update contents
- Rename "Building Libc++" to "Vendor Documentation" and update contents

The "BuildingLibcxx" and "UsingLibcxx" pages have basically been used for
vendor and user documentation respectively. However, they were named in
a way that doesn't really make that clear. Renaming the pages now gives
us a location to clearly document what we target at vendors and what we
target at users, and to do that separately.

…ns (llvm#105455)

This allows the use a single wider operation with a restricted EVL
instead of padding the vector with the neutral element.

For RISCV specifically, it's worth noting that an alternate padded
lowering is available when VL is one less than a power of two, and LMUL
<= m1. We could slide the vector operand up by one, and insert the
padding via a vslide1up. We don't currently pattern match this, but we
could. This form would arguably be better iff the surrounding code
wanted VL=4. This patch will force a VL toggle in that case instead.

Basically, it comes down to a question of whether we think odd sized
vectors are going to appear clustered with odd size vector operations,
or mixed in with larger power of two operations.

Note there is a potential downside of using vp nodes; we loose any
generic DAG combines which might have applied to the widened form.

…lvm#104689)

This is a fairly narrow transform (at the moment) to reduce the VLs of
instructions feeding a store with a smaller VL. Note that the goal of
this transform isn't really to reduce VL - it's to reduce VL *toggles*.
To our knowledge, small reductions in VL without also changing LMUL are
generally not profitable on existing hardware.

For a single use instruction without side effects, fp exceptions, or a
result dependency on VL, reducing VL is legal if only a subset of
elements are legal. We'd already implemented this logic for vmv.v.v, and
this patch simply applies it to stores as an alternate root.

Longer term, I plan to extend this to other root instructions (i.e.
different kind of stores, reduces, etc..), and add a more general
recursive walkback through operands.

One risk with the dataflow based approach is that we could be reducing
VL of an instruction scheduled in a region with the wider VL (i.e. mixed
mode computations) forcing an additional VL toggle. An example of this
is the @insert_subvector_dag_loop test case, but it doesn't appear to
happen widely. I think this is a risk we should accept.

This patch extends llvm#73964 and
optimises SVE cmp intrinsics to zero vector when predicate is zero.

This patch removes obsolete status pages for projects that were
completed: LLVM 18 release, C++20 Ranges and Spaceship support.

Co-authored-by: Hristo Hristov <zingam@outlook.com>

If we switch over ucmp/scmp and have two switch cases going to the same
destination, we can convert into icmp+br.

Fixes llvm#105632.

…cks.

If the external user of the scalar to be extract is in
unreachable/landing pad block, we can skip counting their cost.

Reviewers: RKSimon

Reviewed By: RKSimon

Pull Request: llvm#105667

Static analyser tool cppcheck flags ordered comparison with `bool`s.
Replace with equivalent logical operators to prevent this.

Closes llvm#102912

This allows combining some test files that were only split because
adding new RUN lines introduced too much churn in the checks.

This allows us to handle return values that are too large to fit in x10
and x11. They will be converted to a sret by passing a pointer to where
to store the return value.

…d_Resume calls (llvm#105513)

Similar to the fix for llvm#57469, ensure that the other `_Unwind_Resume`
call emitted by DwarfEHPrepare has a debug location if needed.

This fixes nbdd0121/unwinding#34.

SLP vectorizer has an estimation for gather/buildvector nodes, which
contain some scalar loads. SLP vectorizer performs pretty similar (but
large in SLOCs) estimation, which not always correct. Instead, this
patch implements clustering analysis and actual node allocation with the
full analysis for the vectorized clustered scalars (not only loads, but
also some other instructions) with the correct cost estimation and
vector insert instructions. Improves overall vectorization quality and
simplifies analysis/estimations.

Reviewers: RKSimon

Reviewed By: RKSimon

Pull Request: llvm#104144

…05676)

…ee (llvm#105576)

In f9f3316, Adrian fixed an issue where LLDB wouldn't update the
target's architecture when the process reported a different triple that
only differed in its sub-architecture.

This unintentionally regressed core file debugging when the core file
reports the base architecture (e.g. armv7) while the main binary knows
the correct CPU subtype (e.g. armv7em). After the aforementioned change,
we update the target architecture from armv7em to armv7. Fix the issue
by trusting the target architecture over the ProcessMachCore process.

rdar://133834304

…105677)

An assembly input with

>   .fpu fp-armv8-fullfp16-d16

crashes the compiler because the ELF FPU attribute emitter misses the
respective entry. This patch fixes this.

Interestingly, compiling with -mfpu=fp-armv8-fullfp16-d16 does not cause
the crash because FPv5_D16 is an alias in the compiler and

>   .fpu fpv5-d16

is emitted instead, which does not crash.

The existing .fpu directive test with multiple FPUs serves the purpose
of verifying that each possible FPU option is defined, but does not
trigger the crash because only the last .fpu directive goes effectively
down the code path. Therefore one test for each FPU is required.

Fixes llvm#105674.

This mirrors what GISel already does, extending the existing lowering of
aarch64_neon_saddlv/aarch64_neon_uaddlv to SADDLV/UADDLV. This allows us
to remove some tablegen patterns, and provides a little nicer codegen in
places as the nodes represent the result being in a vector register
correctly.

…" (llvm#105601)

This reverts commit 2704b80
and relands llvm#104404.

The Darwin should not fail after llvm#105599.

This patch fixes warnings of the form:

  llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:9300:23: error: loop
  variable '[E, Idx]' creates a copy from type 'const value_type' (aka
  'const std::pair<const llvm::slpvectorizer::BoUpSLP::TreeEntry *,
  unsigned int>') [-Werror,-Wrange-loop-construct]

This patch fixes:

  llvm/lib/Target/AArch64/AArch64ISelLowering.cpp:6102:9: error:
  unused variable 'OpVT' [-Werror,-Wunused-variable]

The start state of a new section is `EMS_None`, often leading to a
$d/$x at offset 0. Introduce a MCTargetOption/cl::opt
"implicit-mapsyms" to allow an alternative behavior
(ARM-software/abi-aa#274):

* Set the start state to `EMS_Data` or `EMS_A64`.
* For text sections, add an ending $x only if the final data is not instructions.
* For non-text sections, add an ending $d only if the final data is not data commands.

```
.section .text.1,"ax"
nop
// emit $d
.long 42
// emit $x

.section .text.2,"ax"
nop
```

This new behavior decreases the .symtab size significantly:

```
% bloaty a64-2/bin/clang -- a64-0/bin/clang
    FILE SIZE        VM SIZE
 --------------  --------------
  -5.4% -1.13Mi  [ = ]       0    .strtab
 -50.9% -4.09Mi  [ = ]       0    .symtab
  -4.0% -5.22Mi  [ = ]       0    TOTAL
```

---

This scheme works as long as the user can rule out some error scenarios:

* .text.1 assembled using the traditional behavior is combined with .text.2 using the new behavior
* A linker script combining non-text sections and text sections. The
  lack of mapping symbols in the non-text sections could make them
  treated as code, unless the linker inserts extra mapping symbols.

The above mix-and-match scenarios aren't an issue at all for a
significant portion of users.

A text section may start with data commands in rare cases (e.g.
-fsanitize=function) that many users don't care about. When combing
`(.text.0; .word 0)` and `(.text.1; .word 0)`, the ending $x of .text.0
and the initial $d of .text.1 may have the same address. If both
sections reside in the same file, ensure the ending symbol comes before
the initial $d of .text.1, so that a dumb linker respecting the symbol
order will place the ending $x before the initial $d.

Disassemblers using stable sort will see both symbols at the same
address, and the second will win.

When section ordering mechanisms (e.g. --symbol-ordering-file,
--call-graph-profile-sort, `.text : { second.o(.text) first.o(.text) }`)
are involved, the initial data in a text section following a text
section with trailing data could be misidentified as code, but the issue
is local and the risk could be acceptable.

Pull Request: llvm#99718

…lvm#105517)

Disable fixed-point iteration in all AMDGPU Combiners after llvm#102163.

This saves around 2% compile time in ad hoc testing on some large
graphics shaders. I did not notice any regressions in the generated
code, just a bunch of harmless differences in instruction selection and
register allocation.

-Wa,-mmapsyms=implicit enables the alternative mapping symbol scheme
discussed at llvm#99718.

While not conforming to the current aaelf64 ABI, the option is
invaluable for those with full control over their toolchain, no reliance
on weird relocatable files, and a strong focus on minimizing both
relocatable and executable sizes.

The option is discouraged when portability of the relocatable objects is
a concern.
https://maskray.me/blog/2024-07-21-mapping-symbols-rethinking-for-efficiency
elaborates the risk.

Pull Request: llvm#104542

This paper proposes no normative changes, just updates an example in
the standard. It was incorrect for us to have marked it as No in the
first place.

This better aligns with how the feature is being referred to and what
runtimes (V8) are calling it.

…04707)

The previous code made this a compile-time decision but it's not.

…est. (llvm#105586)

Also allow XFAIL for armv7-*-linux-gnueabihf targets, not only for
armv7l-*.

…vm#105460)

TargetProperties.td had a few settings listed as signed integral values,
but the Target.cpp methods reading those values were reading them as
unsigned. e.g. target.max-memory-read-size, some accesses of
target.max-children-count, still today, previously
target.max-string-summary-length.

After Jonas' change to use templates to read these values in
https://reviews.llvm.org/D149774, when the code tried to fetch these
values, we'd eventually end up calling OptionValue::GetAsUInt64 which
checks that the value is actually a UInt64 before returning it; finding
that it was an SInt64, it would drop the user setting and return the
default value. This manifested as a bug that target.max-memory-read-size
is never used for memory read.

target.max-children-count is less straightforward, where one read of
that setting was fetching it as an int64_t, the other as a uint64_t.

I suspect all of these settings were originally marked as SInt64 so a
user could do -1 for "infinite", getting it static_cast to a UINT64_MAX
value along the way. I can't find any documentation for this behavior,
but it seems like something Greg would have done. We've partially lost
that behavior already via
llvm#72233 for
target.max-string-summary-length, and this further removes it.

We're still fetching UInt64's and returning them as uint32_t's but I'm
not overly pressed about someone setting a count/size limit over 4GB.

I added a simple API test for the memory read setting limit.

…aths call a `cold` function"

Fixed up the uar test that was failing. It seems with the new `cold`
attribute the order of the functions is different. As far as I can
tell this is not a concern.

Closes llvm#105559

For variable X of type std::optional, X && X.value_or(Y) == Z is
equivalent to X == Z when Y != Z.

Missed IceLakeServer when I updated the other CPUs in 6ec4c9c

This doesn't match uops.info yet - but it matches the existing vpscatterdq/vscatterqpd entries like uops.info says it should

Fixes llvm#105675

Move VPWiden[Load|Store]EVLRecipe::executeto VPlanRecipes.cpp in line
with other ::execute implementations that don't depend on anything
defined in LoopVectorization.cpp

…04635)

PR llvm#102851 marks reference types in union as error on msvc by changing
the clang, which makes 'transform_error.mandates.verify.cpp' no longer
failing on msvc from ToT. However, all libcxx buildbots do not build
clang from source, therefore, this test will still fail on these bots,
which is incorrect. This patch changed the expected error message of
this test so it can pass with both release branch clang and ToT clang.

Summary:
This patch adds all the libc ctype variants. These ignore the locale
ingormation completely, so they're pretty much just stubs. Because these
use locale information, which is system scope, we do not enable building
them outisde of full build mode.

This reverts commit 8f005f8.

Summary:
This patch adds the macros and entrypoints associated with the
`locale.h` entrypoints.  These are mostly stubs, as we (for now and the
forseeable future) only expect to support the C and maybe C.UTF-8
locales in the LLVM libc.

This adds the SPIRV fdot, sdot, and udot intrinsics and allows them to
be created at codegen depending on the target architecture. This
required moving some of the DXIL-specific choices to DXIL instruction
expansion out of codegen and providing it with at a more generic fdot
intrinsic as well.

Removed some stale comments that gave the obsolete impression that type
conversions should be expected to match overloads.

The SPIRV intrinsic handling involves generating multiply and add
operations for integers and the existing OpDot operation for floating
point.

New tests for generating SPIRV float and integer dot intrinsics are
added as well as expanding HLSL tests to include SPIRV generation

Used new dot product intrinsic generation to implement normalize() in SPIRV

Incidentally changed existing dot intrinsic definitions to use
DefaultAttrsIntrinsic to match the newly added inrinsics

Fixes llvm#88056

We have got several customer reporting of slow stepping over the past
year in VSCode.
Profiling shows the slow stepping is caused by `stackTrace` request
which can take around 1 second for certain targets. Since VSCode sends
`stackTrace` during each stop event, the slow `stackTrace` request would
slow down stepping in VSCode. Below is the hot path:

```
               |--68.75%--lldb_dap::DAP::HandleObject(llvm::json::Object const&)
               |          |
               |          |--57.70%--(anonymous namespace)::request_stackTrace(llvm::json::Object const&)
               |          |          |
               |          |          |--54.43%--lldb::SBThread::GetCurrentExceptionBacktrace()
               |          |          |          lldb_private::Thread::GetCurrentExceptionBacktrace()
               |          |          |          lldb_private::Thread::GetCurrentException()
               |          |          |          lldb_private::ItaniumABILanguageRuntime::GetExceptionObjectForThread(std::shared_ptr<lldb_private::Thread>)
               |          |          |          |
               |          |          |          |--53.43%--lldb_private::FunctionCaller::ExecuteFunction(lldb_private::ExecutionContext&, unsigned long*, lldb_private::EvaluateExpressionOptions const&, lldb_private::DiagnosticManager&, lldb_private::Value&)
               |          |          |          |          |
               |          |          |          |          |--25.23%--lldb_private::FunctionCaller::InsertFunction(lldb_private::ExecutionContext&, unsigned long&, lldb_private::DiagnosticManager&)
               |          |          |          |          |          |
               |          |          |          |          |          |--24.56%--lldb_private::FunctionCaller::WriteFunctionWrapper(lldb_private::ExecutionContext&, lldb_private::DiagnosticManager&)
               |          |          |          |          |          |          |
               |          |          |          |          |          |          |--19.73%--lldb_private::ExpressionParser::PrepareForExecution(unsigned long&, unsigned long&, std::shared_ptr<lldb_private::IRExecutionUnit>&, lldb_private::ExecutionContext&, bool&, lldb_private::ExecutionPolicy)
               |          |          |          |          |          |          |          lldb_private::ClangExpressionParser::DoPrepareForExecution(unsigned long&, unsigned long&, std::shared_ptr<lldb_private::IRExecutionUnit>&, lldb_private::ExecutionContext&, bool&, lldb_private::ExecutionPolicy)
               |          |          |          |          |          |          |          lldb_private::IRExecutionUnit::GetRunnableInfo(lldb_private::Status&, unsigned long&, unsigned long&)
               |          |          |          |          |          |          |          |
```

The hot path is added by https://reviews.llvm.org/D156465 which should
at least be disabled for Linux. Note: I am seeing similar performance
hot path on Mac.

This PR hides the feature behind `enableDisplayExtendedBacktrace` option
which needs to be enabled on-demand.

---------

Co-authored-by: jeffreytan81 <jeffreytan@fb.com>

MI300 ISA section 4.5 states there is a hazard between "VALU op which
uses OPSEL or SDWA with changes the result’s bit position" and "VALU op
consumes result of that op"

This includes the case where the second op is SDWA with same dest and
dst_sel != DWORD && dst_unused == UNUSED_PRESERVE. In this case, there
is an implicit read of the first op dst and the compiler needs to
resolve this hazard. Confirmed with HW team.

We model dst_unused == UNUSED_PRESERVE as tied-def of implicit operand,
so this PR checks for that.

MI300_SP_MAS section 1.3.9.2 specifies that CVT_SR_FP8_F32 and
CVT_SR_BF8_F32 with opsel[3:2] !=0 have dest forwarding issue.
Currently, we only add check for CVT_SR_FP8_F32 with opsel[3] != 0 --
this PR adds support opsel[2] != 0 as well

Summary:
This patch adds all the libc ctype variants. These ignore the locale
ingormation completely, so they're pretty much just stubs. Because these
use locale information, which is system scope, we do not enable building
them outisde of full build mode.

llvm#105716)

…le data"

This reverts commit 2c1f064.

Many build failures in: CodeGen/X86/scatter-schedule.ll

Example of a build failure:
https://lab.llvm.org/buildbot/#/builders/155/builds/1675

…vm#105555)

The new helper functions make the intent clearer while hiding
implementation details, including how we handle previously added
entries.  Note that:

- If we are adding a GUID as a GlobalValueSummary::Definition, then we
  override a previously added GlobalValueSummary::Declaration entry
  for the same GUID.

- If we are adding a GUID as a GlobalValueSummary::Declaration, then a
  previously added GlobalValueSummary::Definition entry for the same
  GUID takes precedence, and no change is made.

These have been replaced with atomicrmw.

Move the logic for pre-computing costs of certain instructions to a
separate helper function, allowing re-use in a follow-up patch.

…e functions. (llvm#105499)

This implements Fast-Forward Sequences documented in ARM64EC
ABI https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi.

There are two conditions when linker should generate such thunks:

- For each exported ARM64EC functions.
It applies only to ARM64EC functions (we may also have pure x64
functions, for which no thunk is needed). MSVC linker creates
`EXP+<mangled export name>` symbol in those cases that points to the
thunk and uses that symbol for the export. It's observable from the
module: it's possible to reference such symbols as I did in the test.
Note that it uses export name, not name of the symbol that's exported
(as in `foo` in `/EXPORT:foo=bar`). This implies that if the same
function is exported multiple times, it will have multiple thunks. I
followed this MSVC behavior.

- For hybrid_patchable functions.
The linker tries to generate a thunk for each undefined `EXP+*` symbol
(and such symbols are created by the compiler as a target of weak alias
from the demangled name). MSVC linker tries to find corresponding
`*$hp_target` symbol and if fails to do so, it outputs a cryptic error
like `LINK : fatal error LNK1000: Internal error during
IMAGE::BuildImage`. I just skip generating the thunk in such case (which
causes undefined reference error). MSVC linker additionally checks that
the symbol complex type is a function (see also llvm#102898). We generally
don't do such checks in LLD, so I made it less strict. It should be
fine: if it's some data symbol, it will not have `$hp_target` symbol, so
we will skip it anyway.

There are cases where VPlans contain some simplifications that are very
hard to accurately account for up-front in the legacy cost model. Those
cases are caused by un-simplified inputs, which trigger the assert
ensuring both the legacy and VPlan-based cost model agree on the VF.

To avoid false positives due to missed simplifications in general, only
trigger the assert if the chosen VPlan doesn't contain any additional
simplifications.

Fixes llvm#104714.
Fixes llvm#105713.

libunwind shouldn't know that compact_unwind_encoding.h is part of a
MachO module that it doesn't own. Delete the mach-o module map, and let
whatever is in charge of the mach-o directory be the one to say how its
module is organized and where compact_unwind_encoding.h fits in.

…102622)

Introduce the `-fsanitize=realtime` flag in clang driver

Plug in the RealtimeSanitizer PassManager pass in Codegen, and attribute
a function based on if it has the `[[clang::nonblocking]]` function
effect.

Diagnose this early after parsing declaration specifiers; this allows us
to issue a better diagnostic. This also checks for `concept friend` and
concept declarations w/o a template-head because it’s easiest to do that
at the same time.

Fixes llvm#45182.

… in lit internal shell (llvm#104880)

This patch rewrites tests to remove the use of the `unset` command,
which is not supported in the lit internal shell. The tests now use the
`env -u` to unset environment variables.

The `unset` command is used in shell environments to remove the
environment variable. However, because the lit internal shell does not
support the `unset` command, using it in tests would result in errors or
other unexpected behavior. To overcome this limitation, the tests have
been updated to use the `env -u` command instead. `env -u` is supported
by lit and effectively removes specified environment variables. This
allows the tests to achieve the same goal of unsetting environment
variables while ensuring compatibility with the lit internal shell.

This change is relevant for [[RFC] Enabling the Lit Internal Shell by
Default](https://discourse.llvm.org/t/rfc-enabling-the-lit-internal-shell-by-default/80179/3)
Fixes: llvm#102397

Fix a bug found when coalescing loops which have iteration arguments,
such that the inner loop's terminator may have operands of the inner
loop iteration arguments which are about to be replaced by the outer
loop's iteration arguments.

The current flow leads to crush within the IR code.

…105579)

- Add reverse iterators and `value_type` to StringRef.
- Add unit test for all 4 iterator flavors.
- This prepares StringRef to be used with `SequenceToOffsetTable`.

llvm#105744)

…r (llvm#102622)"

This reverts commit d010ec6.

Build failure: https://lab.llvm.org/buildbot/#/builders/159/builds/4466

This patch fixes:

  llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:7245:1: error:
  unused function 'planContainsAdditionalSimplifications'
  [-Werror,-Wunused-function]

I missed this one when I introduced helper functions in:

  commit 3082a38
  Author: Kazu Hirata <kazu@google.com>
  Date:   Thu Aug 22 12:06:47 2024 -0700

)

This fixes a crash introduced by my
ac6e1fd.

I had failed to consider the case where a vector is truncated to an
illegal element type. The resulting intermediate VT wasn't an MVT and
we'd fail an assertion. Surprisingly, SLP does query illegal element
types in some cases.

This patch implements sandboxir::CatchReturnInst mirroring
llvm::CatchReturnInst.

…nalysis (llvm#104906)" (llvm#105752)

Revert as it breaks libc++ tests, see llvm#104906.

This reverts commit c368a72.

…4866)

Noticed that the release notes currently have a weird order: C++17,
C++14(!), C++20, C++23, C++2c. Reorder them in reverse chronological
order, which also matches the [status
page](https://clang.llvm.org/cxx_status.html).