* Replace "we" with either "you" (when talking to the reader) or "lldb"
(when talking about the project).
* Refer to lldb as lldb not LLDB, to match what the user sees on
the command line (I am going to come back later and put the proper name in places where it's talking about the projects themselves)
* Remove a bunch of contractions for example "won't". Which don't (pun
intended) seem like a big deal at first but even I as a native English
speaker find the text clearer with them expanded.
* Use RST's plain text highlighting for keywords and command names.
* Split some very long lines for easier editing in future.

Fixes #89544

Previously ObjectLinkingLayer held unique ownership of Plugins, and links
always used the Layer's plugin list at each step. This can cause problems if
plugins are added while links are in progress however, as the newly added
plugin may receive only some of the callbacks for links that are already
running.

In this patch each link gets its own copy of the pipeline that remains
consistent throughout the link's lifetime, and it is guaranteed that Plugin
objects (now with shared ownership) will remain valid until the link completes.

Coding my way home: 9.80469S, 139.03167W

There were two diffs that introduced some options useful when you build
modules externally and cannot rely on file modification time as the key
for detecting input file changes:
- [D67249](https://reviews.llvm.org/D67249) introduced the
`-fmodules-validate-input-files-content` option, which allows the use of
file content hash in addition to the modification time.
- [D141632](https://reviews.llvm.org/D141632) propagated the use of
`-fno-pch-timestamps` with Clang modules.

There is a problem when the size of the input file (header) is not
modified but the content is. In this case, Clang cannot detect the file
change when the `-fno-pch-timestamps` option is used. The
`-fmodules-validate-input-files-content` option should help, but there
is an issue with its application: it's not applied when the modification
time is stored as zero that is the case for `-fno-pch-timestamps`.

The issue can be fixed using the same trick that was applied during the
processing of `ForceCheckCXX20ModulesInputFiles`:
```
  // When ForceCheckCXX20ModulesInputFiles and ValidateASTInputFilesContent
  // enabled, it is better to check the contents of the inputs. Since we can't
  // get correct modified time information for inputs from overriden inputs.
  if (HSOpts.ForceCheckCXX20ModulesInputFiles && ValidateASTInputFilesContent &&
      F.StandardCXXModule && FileChange.Kind == Change::None)
    FileChange = HasInputContentChanged(FileChange);
```
The patch suggests the solution similar to the presented above and
includes a LIT test to verify it.

For the platform and extension doc.

Also add links in the extension doc to the GDB specs we're extending.

This patch fix the crash reported in:
https://github.com/llvm/llvm-project/issues/90589

This takes the form of three consecutive but related changes:
- Mark the fast path of BumpPtrAllocator as likely-taken.
- Move the slow path of BumpPtrAllocator to a separate function.
- Mark the slow path of BumpPtrAllocator as noinline.

Overall, this saves geomean 0.4% userspace instructions on CTMark -O3,
and 0.98% on CTMark -O0 -g.


http://llvm-compile-time-tracker.com/compare.php?from=e1622e189e8c0ef457bfac528f90a7a930d9aad2&to=9eb53a4ed3af4a55e769ae1dd22d034b63d046e3&stat=instructions%3Au

This matches what comes out of isel since
a63bd7e9. It also adds the undef flag to
more closely match the output after regalloc, which will help with the test
diffs in #70549

Canonicalize getelementptr instructions for scalable vector types into
ptradd representation with an explicit llvm.vscale call. This
representation has better support in BasicAA, which can reason about
llvm.vscale, but not plain scalable GEPs.

Reverts llvm/llvm-project#90180

See `llvm/unittests/IR/BasicBlockDbgInfoTest.cpp` for a test case.

Follow up to #90310, limit the tune up only to ThinLTO pre-link as
coroutine passes are not in MonoLTO backend

When delayed privatization is enabled, this PR emits the deallocation
logic to the newly introduced `dealloc` region on `omp.private` ops.

A pack indexing type can appear in a larger pack expansion, e.g
`Pack...[pack_of_indexes]...` so we need to temporarily disable
substitution of pack elements.

Besides, this patch also fixes an assertion failure in
`PackIndexingExpr::classify`: dependent `PackIndexingExpr`s are always
LValues and thus we don't need to consider their `IndexExpr`s.

Fixes https://github.com/llvm/llvm-project/issues/88925



---------

Co-authored-by: cor3ntin <corentinjabot@gmail.com>

Reverts llvm/llvm-project#90679

Fixes #60040.

This patch updates the compatibility checks for CUDA attribute iin
preparation to implement the matching rules described in section 3.2.3.
We this patch the compiler will still emit an error when there is
multiple specific procedures that matches since the matching distances
is not yet implemented. This will be done in a separate patch.


https://docs.nvidia.com/hpc-sdk/archive/24.3/compilers/cuda-fortran-prog-guide/index.html#cfref-var-attr-unified-data

gpu=unified and gpu=managed are not part of this patch since these
options are not recognized by flang yet.

LoadLibraryW will lookup dlls in user directories if its search path is
left unrestricted. This is a security vulnerability as one can name a
shared library the same as that of a system dll in order to run
arbitrary code when the shared library is loaded from the path in a user
directory. This change modifies it to only search within sys32 when
loading dbghelp.dll.

/llvm-project/cross-project-tests/debuginfo-tests/llvm-prettyprinters/gdb/mlir-support.cpp:41:16:
 error: 'cast' is deprecated: Use mlir::cast<U>() instead [-Werror,-Wdeprecated-declarations]
    VectorType.cast<mlir::ShapedType>(), llvm::ArrayRef<float>{2.0f, 3.0f});
               ^
/llvm-project/llvm/../mlir/include/mlir/IR/Types.h:345:9: note: 'cast' has been explicitly marked deprecated here
U Type::cast() const {
        ^
/llvm-project/cross-project-tests/debuginfo-tests/llvm-prettyprinters/gdb/mlir-support.cpp:41:16:
 error: 'cast<mlir::ShapedType>' is deprecated: Use mlir::cast<U>() instead [-Werror,-Wdeprecated-declarations]
    VectorType.cast<mlir::ShapedType>(), llvm::ArrayRef<float>{2.0f, 3.0f});
               ^
/llvm-project/llvm/../mlir/include/mlir/IR/Types.h:112:5: note: 'cast<mlir::ShapedType>' has been explicitly marked deprecated here
  [[deprecated("Use mlir::cast<U>() instead")]]
    ^
2 errors generated.

Previous fix #90549 didn't completely address the Buildbot failures.
Some target may not recognize the target triple. This time, only run the
test under x86_64-linux.

The new operation is just an abstract attribute that is attached to
[hl]fir.declare operations of dummy arguments of a subroutine.
Dummy arguments of the same subroutine refer to the same
fir.dummy_scope, so they can be recognized as such during FIR AliasAnalysis.
Note that the fir.dummy_scope must be specific to the runtime
instantiation of a subroutine, so any MLIR inlining/cloning should duplicate and
unique it vs using the same fir.dummy_scope for different runtime instantiations.
This is why I made it an operation rather than an attribute.
The new operation uses a write effect on DebuggingResource, same as
[hl]fir.declare, to avoid optimizing it away.

If `LLVM_APPEND_VC_REV` is on, add the git revision to the `.file`
string. The revision can be set with `LLVM_FORCE_VC_REVISION`.

Before:
`.file	"git_revision.cpp",,"LLVM version 19.0.0git"`

After:
`.file	"git_revision.cpp",,"LLVM version 19.0.0git (LLVM_REVISION)"`

Previously if the producer tensor.unpack op had "unpadding" semantics,
the folding pattern would construct a destination that does not match
with the result type of the transpose. Because both ops are DPS we can
just reuse the destination of the transpose.

Additionally cleans up a bunch of trailing whitespace in the test file.

If this flag is set, Xor will not be considered AddLike. If an Xor were
treated as an Add it may wrap. If we can prove there would be no carry out and
thus no wrap, the Xor would be turned into a disjoint Or by DAGCombine.

Use this new flag to fix a bug in X86 where an Xor is incorrectly being treated
as an NUWAdd.

Fixes #90668.

This reverts commit 7a8d15e9.

Add validation in the FileList reader to check that the headers exist and use similar diagnostics in Options.cpp

```
SelectionDAG has 17 nodes:
  t0: ch,glue = EntryToken
    t6: i64,ch = CopyFromReg t0, Register:i64 %2
  t8: i1 = truncate t6
          t4: i64,ch = CopyFromReg t0, Register:i64 %1
        t7: i1 = truncate t4
            t2: i64,ch = CopyFromReg t0, Register:i64 %0
          t10: i64,i1 = saddo t2, Constant:i64<1>
        t11: i1 = or t8, t10:1
      t12: i1 = select t7, t8, t11
    t13: i64 = any_extend t12
  t15: ch,glue = CopyToReg t0, Register:i64 $x10, t13
  t16: ch = RISCVISD::RET_GLUE t15, Register:i64 $x10, t15:1
```

`OtherOpVT` should be i1, but `OtherOp->getValueType(0)` returns `i64`,
which ignores `ResNo` in `SDValue`.

Fix https://github.com/llvm/llvm-project/issues/90652.

I accidentally named it pr90688 instead of pr90668.

This patch fixes:

  bolt/lib/Rewrite/LinuxKernelRewriter.cpp:855:12: error: variable
  'PrevIP' set but not used [-Werror,-Wunused-but-set-variable]

This PR implements a part of WG14 N2653:
 - Define C23 char8_t
 - Define C11 char16_t
 - Define C11 char32_t
 
 Missing goals are:
- The type of UTF-8 character literals is changed from unsigned char to
char8_t. (Since UTF-8 character literals already have type unsigned
char, this is not a semantic change).
- New mbrtoc8() and c8rtomb() functions declared in <uchar.h> enable
conversions between multibyte characters and UTF-8.
    - A new ATOMIC_CHAR8_T_LOCK_FREE macro.
    - A new atomic_char8_t typedef name.

Update the `AreCompatibleCUDADataAttrs` function to return true when one
argument has the `PINNED` attribute and the other argument is just host
data.

This changes the handling of -fno-unsafe-fp-math to stop having that
option imply -ftrapping-math. In gcc, -fno-unsafe-math-optimizations
sets -ftrapping-math, but that dependency is based on the fact the
-ftrapping-math is enabled by default in gcc. Because clang does not
enable -ftrapping-math by default, there is no reason for
-fno-unsafe-math-optimizations to set it.

On the other hand, -funsafe-math-optimizations continues to imply
-fno-trapping-math because this option necessarily disables strict
exception semantics.

This fixes https://github.com/llvm/llvm-project/issues/87523

Added a limit of 128 incoming values at max for PHIs nodes to be
vectorized plus improved performance by using logarithmic search instead
of linear if the number of incoming values is > 4.

During analysis, we incorrectly leave the offset part of an address info
struct
as zero, when in actual fact we failed to decompose it into base +
offset.
This results in incorrectly assuming that the address is adjacent to
another store
addr. To fix this we wrap the offset in an optional<> so we can
distinguish between
real zero and unknown.

Fixes issue #90242