Progress:

Changes

More master to main updates

jenkins/jobs: Add timeout to the lnt-ctmark-* jobs

This is so that these don't end up stuck and running forever in case of
any issues.

[flang][fir][NFC] Move remaining types to TableGen type definition

Move the remaing of FIR types to TableGen type definition. This follow suggestion in D96422.

Reviewed By: schweitz, jeanPerier, rriddle

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

[flang][fir][NFC] Remove dead code.

This patch removes OpaqueAttr as it is no longer used.

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

[docs] Add a release note for the removing of -Wreturn-std-move-in-c++11

`-Wreturn-std-move-in-c++11` has been removed in fbee4a0c79cc4ee87c34e51342742a5bc6fcf872.

Reviewed By: aaronpuchert, amccarth

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

[Coroutine] Check indirect uses of alloca when checking lifetime info

In the existing logic, we look at the lifetime.start marker of each alloca, and check all uses of the alloca, to see if any pair of the lifetime marker and an use of alloca crosses suspension point.
This approach is unfortunately incorrect. An use of alloca does not need to be a direct use, but can be an indirect use through alias.
Only checking direct uses can miss cases where indirect uses are crossing suspension point.
This can be demonstrated in the newly added test case 007.
In the test case, both x and y are only directly used prior to suspend, but they are captured into an alias, merged through a PHINode (so they couldn't be materialized), and used after CoroSuspend.
If we only check whether the lifetime starts cross suspension points with direct uses, we will put the allocas to the stack, and then capture their addresses in the frame.

Instead of fixing it in D96441 and D96566, this patch takes a different approach which I think is better.
We still checks the lifetime info in the same way as before, but with two differences:
1. The collection of liftime.start is moved into AllocaUseVisitor to make the logic more concentrated.
2. When looking at lifetime.start and use pairs, we not only checks the direct uses as before, but in this patch we check all uses collected by AllocaUseVisitor, which would include all indirect uses through alias. This will make the analysis more accurate without throwing away the lifetime optimization.

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

[NFC][AIX] Rename aix-csr-vector.ll to aix-csr-vector-extabi.ll

[NARY][NFC] New tests for upcoming changes.

[docs][JITLink] Reintroduce JITLink design/API doc with fixes and improvements.

This document was originally introduced in ab4648504b2, and was reverted in
912bc4980e9 while I investigated a number of shpinx bot errors. This commit
reintroduces the document with fixes for those errors, as well as some
improvements to the wording and formatting.

[RISCV] Reuse existing SDLoc and XLenVT in the switch in RISCVISelDAGToDAG::Select. NFC

A SDLoc and XLenVT were already created above the switch.

OpenMP: Fix object clobbering issue when using save-temps

There are two preconditions to reproduce the issue,
 1. Use -save-temps option
 2. Provide the -o option with name equal to the input file name
    without the file extension. For e.g. clang a.c -o a

With the -o specified, the AssembleJobAction after OffloadWrapperJobAction
will produce the object file with same name as host code object file.
Due to this clash, the OffloadWrapperAction overwrites the initial host
object file, which results in lld error. This also fixes the `multiple definition of __dummy.omp_offloading.entry'` issue in D96769 .

Reviewed By: jdoerfert

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

[debugserver] Fix logic to extract app bundle from file path

Fix the logic to find the app bundle in a path by correctly accounting
for paths containing multiple occurrences of `.app`. The new logic will
correctly extract `com.app.Foo.app` from `com.app.Foo.app/com.app.Foo`.

rdar://74666208

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

[clang][RecoveryAST] Add design doc to clang internal manual.

Hopefully it would be useful for new developers.

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

[mlir] Fix emitting attribute documentation

This fixes the documentation emitted for type parameters. Also adds a
missing empty line, rendered as line break in mark down.

Co-authored-by: Simon Camphausen <simon.camphausen@iml.fraunhofer.de>

Reviewed By: rriddle

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

[mlir][nfc] Fix typo in documentation comment

[clang][cli] Add MarshallingInfoEnum multiclass

This patch introduces a tablegen multiclass called `MarshallingInfoEnum`. It has the same semantics as `MarshallingInfoString` had in combination with `AutoNormalizeEnum`, but it's easier to use and follows the convention used for other `MarshallingInfoXxx` multiclasses.

Reviewed By: dexonsmith

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

[clang][cli] Remove marshalling from Opt{In,Out}FFlag

We can now express all marshalling semantics in `Opt{In,Out}FFlag` via `BoolFOption`.

This patch moves remaining `Opt{In,Out}FFlag` instances using marshalling to `BoolFOption` and removes marshalling capabilities from `Opt{In,Out}FFlag` entirely.

This simplifies the decisions developers have to make when creating new boolean options:
  * For simple cc1 flag pairs, use `Bool{,F,G}Option`.
  * For cc1 flag pairs that require complex marshalling logic, use `Opt{In,Out}FFlag` and implement marshalling manually.

Reviewed By: dexonsmith

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

[clangd] NFC, remove an extra "class" keyword.

[AArch64] Add abs intrinsic costs

This patch adds cost-modelling for abs vector intrinsic.

Change-Id: I89007971bfb15f5b4a02a2eadfd43018e9a73976

[clang][cli] Store additional optimization remarks info

After a revision of D96274 changed `DiagnosticOptions` to not store all remark arguments **as-written**, it is no longer possible to reconstruct the arguments accurately from the class.

This is caused by the fact that for `-Rpass=regexp` and friends, `DiagnosticOptions` store only the group name `pass` and not `regexp`. This is the same representation used for the plain `-Rpass` argument.

Note that each argument must be generated exactly once in `CompilerInvocation::generateCC1CommandLine`, otherwise each subsequent call would produce more arguments than the previous one. Currently this works out because of the way `RoundTrip` splits the responsibilities for certain arguments based on what arguments were queried during parsing. However, this invariant breaks when we move to single round-trip for the whole `CompilerInvocation`.

This patch ensures that for one `-Rpass=regexp` argument, we don't generate two arguments (`-Rpass` from `DiagnosticOptions` and `-Rpass=regexp` from `CodeGenOptions`) by shifting the responsibility for handling both cases to `CodeGenOptions`. To distinguish between the cases correctly, additional information is stored in `CodeGenOptions`.

The `CodeGenOptions` parser of `-Rpass[=regexp]` arguments also looks at `-Rno-pass` and `-R[no-]everything`, which is necessary for generating the correct argument regardless of the ordering of `CodeGenOptions`/`DiagnosticOptions` parsing/generation.

Reviewed By: dexonsmith

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

[clang][cli] Round-trip the whole CompilerInvocation

Finally, this patch moves from round-tripping one `CompilerInvocation` at a time to round-tripping the invocation as a whole.

This patch includes only the code required to make round-tripping the whole invocation work. More cleanups will be done in a follow-up patch.

Depends on D96847, D97041 & D97042.

Reviewed By: dexonsmith

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

AArch64: relax address-space assertion in FastISel.

Some people are using alternative address spaces to track GC data, but
otherwise they behave exactly the same. This is the only place in the backend
we even try to care about it so it's really not achieving anything.

[CodeGen] Canonicalise adds/subs of i1 vectors using XOR

When calling SelectionDAG::getNode() to create an ADD or SUB
of two vectors with i1 element types we can canonicalise this
to use XOR instead, where 1+1 is treated as wrapping around
to 0 and 0-1 wraps to 1.

I've added the following tests for SVE targets:

  CodeGen/AArch64/sve-pred-arith.ll

and modified some X86 tests to reflect the much simpler codegen
required.

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

Prefer /usr/bin/env xxx over /usr/bin/xxx where xxx = perl, python, awk

Allow users to use a non-system version of perl, python and awk, which is useful
in certain package managers.

Reviewed By: JDevlieghere, MaskRay

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

[lldb] Let ClangASTImporter assert that the target AST has an external source

This prevents people from accidentially using this code outside the
intended setup.

[lldb][NFC] Remove some obsolete comments in ClangASTImporter.cpp

The first two comments are incomplete and reference obsolete code. The
last one is just commented out code (that also doesn't look correct).

Support standalone build of clang-tidy unittest

Apply the same pattern as the one used in clangd/unittests/CMakeLists.txt

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

[X86][SSE] Move unaryshuffle(xor(x,-1)) -> xor(unaryshuffle(x),-1) fold into helper. NFCI.

We should be able to extend this "canonicalizeShuffleWithBinOps" to handle more generic binop cases where either/both operands can be cheaply shuffled.

[NARY-REASSOCIATE] Support reassociation of min/max

Support reassociation for min/max. With that we should be able to transform min(min(a, b), c) -> min(min(a, c), b) if min(a, c) is already available.

Reviewed By: mkazantsev

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

[X86] Regenerate sdiv_fix.ll tests. NFCI.

[NFC] Fix build failure after 83d134c3c4222e8b8d3d90c099f749a3b3abc8e0

[RISCV] Unify scalable- and fixed-vector EXTRACT_SUBVECTOR lowering

This patch unifies the two disparate paths for lowering
EXTRACT_SUBVECTOR operations under one roof. Consequently, with this
patch it is possible to support any fixed-length subvector extraction,
not just "cast-like" ones.

Reviewed By: craig.topper

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