When LLVM is built under MSVC and libcxx ABI is set to 2, the
'copy_move.pass' test will unexpectedly pass. This patch mitigate
this issue by setting this test will only expecting FAIL when libcxx
ABI version is set to 1.

This is a re-land of be9f55f4

Differential Revision: https://reviews.llvm.org/D155760
Fixes: https://github.com/llvm/llvm-project/issues/63442

We don't support this as a argument or return type, it's always promoted to <2 x s32>.

Performing the widening prevents us from having selection failures due to unsupported
extends.

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

Since UUID generation in lld is fast this is rarely used but it can be
helpful to avoid temporary issues like https://github.com/llvm/llvm-project/issues/63961

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

This reverts commit be9f55f4.

The commit was both not approved by the libc++ review group, and also
the only change it contained was incorrect.

This changes the definition if `isSectionBitcode` to only be valid for the
`.llvm.lto` section, since this API is only called from LTO, and the
`.llvmbc` section was not intended to be used for LTO. This allows the
gold plugin to keep its existing behavior without introducing any
significant changes.

Depends on D146778

Reviewed By: MaskRay

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

This patch adds support to lld for --fat-lto-objects. We add a new
--fat-lto-objects flag to LLD, and slightly change how it chooses input
files in the driver when the flag is set.

Fat LTO objects contain both LTO compatible IR, as well as generated object
code. This allows users to defer the choice of whether to use LTO or not to
link-time. This is a feature available in GCC for some time, and makes the
existing -ffat-lto-objects flag functional in the same way as GCC's.

If the --fat-lto-objects option is passed to LLD and the input files are fat
object files, then the linker will chose the LTO compatible bitcode sections
embedded within the fat object and link them together using LTO. Otherwise,
standard object file linking is done using the assembly section in the object
files.

Original RFC: https://discourse.llvm.org/t/rfc-ffat-lto-objects-support/63977

Depends on D146777

Reviewed By: MaskRay

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

When writing this initially I missed including the resource stride.
This change adds the resources stride to the serialized value.

I've also extended the testing and error reporting around parsing PSV
information. This adds tests to verify that the reader produces
meaningful error messages for malformed DXContainer files, and a test
that verifies the resource stride is respected in the reader even if
the stride isn't an expected or known value (as would happen if the
format changes in the future).

This is part of #59479.

Reviewed By: bogner, bob80905

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

https://reviews.llvm.org/rG8acdcf4016876d122733991561be706b64026e73 didn't include handling for the fact that `throw`'s implementation takes a pointer to a type's `typeinfo` struct, which implies that its signature needs to change as well. This corrects that and adds a test.

Reviewed By: rjmccall

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

When LLVM is built under MSVC and libcxx ABI is set to 2, the
'copy_move.pass' test will unexpectedly pass. This patch mitigate this
issue by setting this test will only expecting FAIL when libcxx ABI
version is set to 1.

Differential Revision: https://reviews.llvm.org/D155760
Fixes: https://github.com/llvm/llvm-project/issues/63442

Looks like a couple of flang bots are broken by this change. Reverting
to investigate.

This reverts commit b2eda85f.

Following recent changes switching from xxh64 to xxh32 for better
hashing performance (e.g., D154813). I am not familiar with this use
case, but this change will ensure that the lld executable doesn't need
xxHash64 after wasm-ld migrates.

When we have both explicitly included and excluded option sets, we
were excluding anything from the latter set regardless of what was in
the former. This doesn't compose well and led to an overly complicated
design around DXC options where a third flag was introduced to handle
options that overlapped between DXC and CL.

With this change we check the included options before excluding
anything from the exclude list, which allows for options that are in
multiple categories to be handled in a sensible way. This allows us to
remove CLDXCOption but should otherwise be NFC.

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

Following recent changes switching from xxh64 to xxh32 for better
hashing performance (e.g., D154813). These particular instances likely
have negligible time, but this change moves us toward removing xxHash64.

The type hash for -fsanitize=function will change, following a recent
change D148785 (not in any release yet) to the type hash scheme, though
sanitizers don't sign up for cross-version compatibility anyway.

The MicrosoftMangle instance is for internal symbols that need no
compatibility guarantee, as emphasized by the comment.

The safe-buffer analysis analyzes TypeLocs of types of variable
declarations in order to get source locations of them.

However, in some cases, the source locations of a TypeLoc are not
valid. Using invalid source locations results in assertion violation
or incorrect analysis or fix-its.

It is still not clear to me in what circumstances a TypeLoc does not
have valid source locations (it looks like a bug in Clang to me, but
it is not our responsibility to fix it). So we will conservatively
give up the analysis when required source locations are not valid.

Reviewed By: NoQ (Artem Dergachev)

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

Capture debug_line_str offsets into FileCheck variables.

Reviewed By: #bolt, maksfb, ayermolo

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

Other <angle-quoted> headers are still excluded.

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

If the path components of %clang contain a symlink, e.g.

```
% cd /tmp; ln -s Rel xxx
% /tmp/xxx/bin/clang --target=powerpc-unknown-eabi -xc /dev/null '-###'
InstalledDir: /tmp/xxx/bin
...
"-internal-isystem" "/tmp/Rel/bin/../lib/clang-runtimes/powerpc-unknown-eabi/include"
```

the test will fail. Such commands should use -no-canonical-prefixes, or
derive the include and library paths from cc1 -isysroot using driver
--sysroot.

The lowering of calls/expressions unconditionally inserts DestroyOp
clean-up for hlfir.expr values, which is wrong in the case where
the value is used as a result of the elemental operation created
during the implied-do lowering. A cleaner fix could be to avoid
DestroyOp insertion at all, but I have not figure out an easy
way to do it. The DestroyOp look-up I used seems to be quite
reliable, so it should just work.

Reviewed By: clementval

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

When hlfir.assign is lowered into simple load/store,
we may still need to finalize the LHS.
The patch passes `needFinalization` to `genScalarAssignment`
for LHS of any derived type, so some `Destroy` calls
might be redundant. They can be removed later by propagating/deducing
IsFinalizable information about the LHS type.

Reviewed By: clementval

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

Adding assertions will aid users that have bugs or logic mistakes in
their code to receive error messages when debugging.

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

isOpaquePointerTy now returns true for all pointers, so we can replace
these with isPointerTy().

Following recent changes switching from xxh64 to xxh32 for better
hashing performance. This particular instance may or may not have
noticeable performance difference, but this change makes us toward
removing xxHash64.

It is possible that a function parameter does not have a name even in
a function definition.  This patch deals with such cases in generating
function overload fix-its for safe buffers.

Reviewed by: NoQ (Artem Dergachev)

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

Currently frame var --regex sometimes searches globals, sometimes it doesn't.
This happens because `StackFrame::GetVariableList` always returns the biggest
list it has, regardless of whether only globals were requested or not. In other
words, if a previous call to `GetVariableList` requested globals, all subsequent
calls will see them.

The implication here is that users of `StackFrame::GetVariableList` are expected
to filter the results of this function. This is what we do for a vanilla
`frame var` command. But it is not what we do when `--regex` is used. This
commit solves the issue by:

1. Making `--regex` imply `--globals`. This matches the behavior of `frame var
<some_name>`, which will also search the global scope.
2. Making the `--regex` search respect the command object options.

See the added test for an example of the oddities this patch addresses. Without
the patch, the test fails. However it could be made to pass by calling a plain
`frame var...

Similar to recent changes to ELF (e.g., commit
f4b4bc2f) and Mach-O to improve hashing
performance.

[lldb-vscode] Creating a new flag for adjusting the behavior of evaluation repl expressions to allow users to more easily invoke lldb commands.

This adds a new flag and lldb runtime command to allow users to manage the behavior of the lldb-vscode evaluate repl request.

When evaluating a repl context this now has runtime managed flag for control how the repl behaviors with the follow values:

* `variable` - the existing behavior, with this mode requests are evaluted in the current frame context as variable expressions. To trigger a lldb command prefix an expression with ` and it will be evaluted as an lldb command.
* `command` - all expressions are evaluated as lldb commands.
* `auto` - An alternative mode that will attempt to determine if the expression is an lldb command or a variable expression. Based off the intepreted results the expression will be evaluted either as a command or an expression.

Additionally, I enabled completions and ensured they work with the new repl expression behavior to provide...

The main op implementation file for SPIR-V grew past 5k LOC. This makes it
take a long time to compile and index with LSPs like clangd.

Pull out the first few SPIR-V extension ops into their own `.cpp` files,
just like we do with `.td` op definitions. This includes the
KHR/NV/Intel coop matrix and the integer dot prod extensions.

I plan to further split this in future revisions.

Reviewed By: antiagainst

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

Correct link in release notes and format of some notes.

Fix the various complex libm selection logic issues from D155310:
- disableMlirComplex is set to false. This means that using mlir complex
is enabled. Yet, the current code still selects libm.
- If we enable mlir complex, we should not check if use approx is
enabled. Namely, we should use mlir complex either if we enable mlir
complex OR use approx is enabled.

To fix the issues, we flip the logic of `disableMlirComplex` to enable
instead. We set it to false by default since the intention from D155310
is to use libm by default. Then we use a logical `&&` with use approx
so that we select libm when BOTH mlir complex and use approx are
disabled.

Reviewed By: vzakhari

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

Summary:
Simple cleanup of the interface so we do not depend on the installed
headers and get everything we need just including rpc_client.h.

Add summary and synthetic data formatters for `llvm::DenseMap`.

This implementation avoids expression evaluation by using a heuristic. However, as
heuristics go, there is a corner case: A single deleted entry (a single "tombstone"),
will result in a child value with an invalid key but a valid value.

Instead of calling `getEmptyKey()` and `getTombstoneKey()` to determine which buckets
are empty, and which contain real key-values, the heuristic scans all buckets to
identify keys that exist only once. These singleton keys are considered valid.

The empty key will always exist multiple times. However the tombstone key may exist
zero, one, or many times. The heuristic has no problems when there are zero or many
tombstones, but when there is exactly one deleted entry (one tombstone), then the
heuristic will incorrectly identify it as valid.

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

This is an alternative to D155288 that can handle other sources of
xori like FP compares. Unfortunately, it misses the i64 setge case
on RV32 in condops.ll.

Reviewed By: asb

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

This fixes some warnings (that were caught as errors) in https://reviews.llvm.org/D155518/.

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

This change is mostly for brevity's sake; but it also paves the way for the `Policy` enum to be reuseable for other situations that require the same three-way semantics.

Reviewed By: Peiming

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

These tests break with msan on the sanitizer-aarch64-linux-bootstrap-msan
builder. Note the x86_64 builder is not affected. To unbreak the CI
temporary disable the tests completely with msan.

The breakage was introduced by D150044.

Link time thinLTO spawns pthreads to parallelize optimization and
codegen of the input bitcode files. On AIX, the default pthread
stack size limit is ~192k for 64-bit programs; insufficient for a
normal LLVM compilation.

Reviewed By: ZarkoCA, MaskRay

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