ule/uge with a constant will be converted to ult/ugt, so there is
no need to handle these variants.

This reverts commit 8d80a452.

The pointer to the invalidates lists needs to be non-const. Though in this case
I don't think it's ever modified.

Also I realised that the invalidate list was being set on svg not vg.
Should be the other way around.

Gep with zero indices will be folded away independently. It will
only be retained for splat geps, for which the transform is not
applicable anyway.

This reverts commit f2c09e5e, due to compilation
failures on buildbots.

This fixes a bug where writing vg during streaming mode
could prevent you reading za directly afterwards.

vg is invalidated just prior to us reading it in AArch64Reconfigure,
but svg was not. This lead to some situations where vg would be
updated or cleared and re-read, but svg would not be.

This meant it had some undefined value which lead to errors
that prevented us reading ZA. Likely we received a lot more
data than we were expecting.

There are at least 2 ways to get into this situation:
* Explicit write by the user to vg.
* We have just stopped and need to get the potentially new svg and vg.

The first is handled by invalidating svg client side before fetching the
new one. This also
covers some but not all of the second scenario. For the second, I've
made writes to vg
invalidate svg by noting this in the register information.

Whichever one of those kicks in, we'll get the latest value of svg.

The bug may depend on timing, I could not find a consistent way
to trigger it. I originally found it when checking whether za
is disabled after a vg change, so I've added checks for that
to TestZAThreadedDynamic.

The SVE VG version of the bug did show up on the buildbot,
but not consistently. So it's possible that TestZAThreadedDynamic
does in fact cover this, but I haven't run it enough times to know.

As ReadRegister always read into a uint64_t, when it called operator=
with uint64_t it was setting the RegisterValue's type to eTypeUInt64
regardless of its size.

This mostly works because most registers are 64 bit, and very few bits
of code rely on the type being correct. However, cpsr, fpsr and fpcr are
in fact 32 bit, and my upcoming register fields code relies on this type
being correct.

Which is how I found this bug and unfortunately is the only way to test
it. As RegisterValue::Type never makes it out via the API anywhere. So
this change will be tested once I start adding register field
information.

This is a new attempt at #69320.

The transform dialect stores a "library module" that the preload pass
can populate. Until now, each pass registered an additional module by
simply pushing it to a vector; however, the interpreter only used the
first of them. This commit turns the registration into "loading", i.e.,
each newly added module gets merged into the existing one. This allows
the loading to be split into several passes, and using the library in
the interpreter now takes all of them into account. While this design
avoids repeated merging every time the library is accessed, it requires
that the implementation of merging modules lives in the
TransformDialect target (since it at the dialect depend on each
other).

This resolves https://github.com/llvm/llvm-project/issues/69111.

Constant values of _BitInt have the bitwith to exactly fit the constant
number. This patch fix a problem in Sema when building an APInt where
the supplied bitwidth can become too small and simply truncate the value
leading to a faulty warning.

!llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang
codegen still generated them and relied on mlir.llvm codegen to LLVM to
turn them into opaque pointers.

This patch update FIR codegen to directly emit and work with LLVM opaque
pointers.

Addresses https://github.com/llvm/llvm-project/issues/69303

- All places generating GEPs need to add an extra type argument with the
base type (the T that was previously in the llvm.ptr<T> of the base).

- llvm.alloca must also be provided the object type. In the process, I
doscovered that we were shamelessly copying all the attribute from
fir.alloca to the llvm.alloca, which makes no sense for the operand
segments. The updated code that cannot take an attribute dictionnary in
the llvm.alloca builder with opaque pointers only propagate the "pinned"
and "bindc_name" attributes to help debugging the generated IR.

- Updating all the places that rely on g...

Fixes #68884.

If clang/test/Driver/cl-offload.cu is run on Unix in a directory whose
absolute pathname starts with `/w`, such as the `/workspace` used by at
least some Jenkins CI setups, then the file name on the clang command
line is misinterpreted as some kind of MSVC warning-control option, and
ignored by the catch-all `_SLASH_w` option in Options.td.

Other clang-cl tests take care to put a `--` before the input file name,
to force clang to treat it as a filename even if it starts with a / and
accidentally looks like a cl option. Do the same here.

OpenACC/OpenMP atomic lowering needs a finer control over expression
lowering. This patch allows mapping evaluate::Expr<T> to mlir::Value so
that any subsequent expression lowering will use these values when an
operand is a mapped Expr<T>.

This is an alternative to
https://github.com/llvm/llvm-project/pull/69866

 From which I took the
test and some of the logic to extract the non-atomic sub-expression.

---------

Co-authored-by: Nimish Mishra <neelam.nimish@gmail.com>

This updates our G_SEXTLOAD support to the same level as G_ZEXTLOAD.
Still missing some legalizer rules for both though.

We weren't legalizing the shift amount to i64.

C++20 comes with std::erase to erase a value from std::vector.  This
patch renames llvm::erase_value to llvm::erase for consistency with
C++20.

We could make llvm::erase more similar to std::erase by having it
return the number of elements removed, but I'm not doing that for now
because nobody seems to care about that in our code base.

Since there are only 50 occurrences of erase_value in our code base,
this patch replaces all of them with llvm::erase and deprecates
llvm::erase_value.

…test

This fixes failures from a recent merge.
[Flang][OpenMP] Port OpenMP single tests to hlfir flow
(https://github.com/llvm/llvm-project/pull/69877)

`PyOperations` are Python-level handles to `Operation *` instances. When
the latter are modified by C++, the former need to be invalidated.
#69746 implements such invalidation mechanism by setting all
`PyReferences` to `invalid`. However, that is not enough: they also need
to be removed from the `liveOperations` map since other parts of the
code (such as `PyOperation::createDetached`) assume that that map only
contains valid refs.

This is required to actually solve the issue in #69730.

Basic way to recursively analyze `select` in `isKnownNonEqual`: `select
%c, %t, %f` is non-equal to `%x` if `%t` is non-equal to `%x` and `%f`
is non-equal to `%x`.

First, expand all truncationg stores and extending loads. Second,
expand everything for `fixedlen_vector_valuetypes`.  Finally, we
selectively turn on ones that can be effectively codegen'd.

Simultaneously, this patch adds floating-point vector types to
load/store patterns. Additional test cases will be included in the IR
instruction test patchs.

Co-authored-by: Harish Chambeti <hchambet@amd.com>

We've been using the backtick as our escape character, however that
leads to a weird experience on VS Code, because on most hosts, as soon
as you type the backtick on VS Code, the IDE will introduce another
backtick. As changing the default escape character might be out of
question because other plugins might rely on it, we can instead
introduce an option to change this variable upon lldb-vscode
initialization.
FWIW, my users will be using : instead ot the backtick.

BlockFrequencyInfo calculates block frequencies as Scaled64 numbers but as a last step converts them to unsigned 64bit integers (`BlockFrequency`). This improves the factors picked for this conversion so that:

* Avoid big numbers close to UINT64_MAX to avoid users overflowing/saturating when adding multiply frequencies together or when multiplying with integers. This leaves the topmost 10 bits unused to allow for some room.
* Spread the difference between hottest/coldest block as much as possible to increase precision.
* If the hot/cold spread cannot be represented loose precision at the lower end, but keep the frequencies at the upper end for hot blocks differentiable.

I think the TODO is stale now.

Some passes has limitation that only support simple terminators:
branch/unreachable/return. Right now, they ask the pass manager to add
LowerSwitch pass to eliminate `switch`. Let's manage such kind of pass
dependency by ourselves. Also add the assertion in the related passes.

This commit was supposed to only change the generic implementation.
Should fix the build bot errors.

Use of long double can be error-prone since it could be one of 80-bit
extended precision float, IEEE 128-bit float, or IBM 128-bit float.
Instead use an explicit xf_float typedef for the remaining cases where
long double is being used in the implementation. This patch does not
touch
the PPC specializations which still use long double.

Some float128 systems (specifically the ones used for aarch64 buildbots)
don't respect signs for long double NaNs. This patch disables the printf
test that was failing due to this.

`tensor.insert_slice` and `tensor.parallel_insert_slice` can share the
same implementation.

This is re-commit of #69392 and also fixes issue #69670 which was
uncovered with the prior commit.
For delayed gather emission it may be incorrect to use stab instruction
as insertion point if it is a PHI operand. For that case insertion point
is adjusted to be at the end of block, ensuring that prior dependecy
vector code is emitted earlier.

This patch also includes:
  - Remove legacy non_imm12 PatLeaf from RISCVInstrInfoZb.td
- Implement a custom GlobalISel operand renderer for TrailingZeros
SDNodeXForm

This was previously passed by value. It used to be passed by non-const
reference, but it was changed to value in D110610. I'm not sure why.

These bugs were found with the new printf long double fuzzing. The long
double inf vs nan bug was introduced when we changed to
get_explicit_exponent. The bitcast msan issue hadn't come up previously,
but isn't a real bug, just a poisoning confusion.

Reference:
(1) OpenMP 5.2 Specification - Seciton 5.4.6

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

The `--stdlib` flag can affect the system headers used by `clang` during
compilation. By default, `clang` will use the platform-installed C++
standard headers, but with `--stdlib=libc++`, `clang` can use headers
included in the distribution for its `libc++` implementation.

Prior to this patch, if `compile_commands.json` specified
`-stdlib=libc++` or an equivalent form and `--query-driver` took effect,
`clangd` would ignore `stdlib` and index based on the platform's
headers. When these mismatch, e.g. due to version differences,
`clangd`'s completions and the actual compilation can differ.

fixes clangd/clangd#1784

---------

Co-authored-by: Chris Carlon <cjc25@cjc25.com>

Raw string literals are a C++ feature first added in C++11.

Fixes https://github.com/clangd/clangd/issues/1795.