Fixes #68987

Early on we load the interpreter (most commonly ld-linux) in
LoadInterpreterModule. Then later when we get the first DYLD rendezvous
we get a list of libraries that commonly includes ld-linux again.

Previously we would load this duplicate, see that it was a duplicate,
and unload it.

Problem was that this unloaded the section information of the first copy
of ld-linux. On platforms where you can place a breakpoint using only an
address, this wasn't an issue.

On ARM you have ARM and Thumb modes. We must know which one the section
we're breaking in is, otherwise we'll go there in the wrong mode and
SIGILL. This happened on ARM when lldb tried to call mmap during
expression evaluation.

To fix this, I am making the assumption that the base address we see in
the module prior to loading can be compared with what we know the
interpreter base address is. Then we don't have to load the module to
know we can ignore it.

This fixes the lldb test suite on Ubuntu versions where
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1927192 has been
fixed. Which was recently done on Jammy.

FEAT_SME_FA64 (smefa64 in Linux cpuinfo) allows the use of the full A64
instruction set while in streaming SVE mode.

See https://developer.arm.com/documentation/ddi0616/latest/ for details.

This means for example if we want to write to the ffr register during or
use floating point registers while in streaming mode, we need this
extension.

I initially was using QEMU which has it by default, and switched to
Arm's FVP which does not. So this change adds a more strict check and
converts most of the tests to use that. It would be possible in some
cases to avoid the offending instructions but it would be a lot of
effort and liable to fail randomly as the C library changes.

It is also my assumption that the majority of systems will have smefa64
as QEMU has chosen to have. If I turn out to be wrong, we can make the
effort to get the tests working without smefa64.

`isAArch64SME` remains for some tests, which are as follows:
* `test_aarch64_dynamic_regset_config` merely checks for the presence of
a register set, which appears for any SME system not just one with
smefa64.
* `test_aarch64_dynamic_regset_config_sme_za_disabled` only needs the ZA
register and does not enter streaming mode.
* `test_sme_not_present` tests for the absence of the SME register set,
so must be skipped if any form of SME is present.
* Various tests in `TestSVERegisters.py` need to know if SME is present
at all to generate an expected SVCR value. Earlier in the callstack
something else checked `isAArch64SMEFA64` already.
* `TestAArch64LinuxTLSRegisters.py` needs to test the `tpidr2` register
if any form of SME is present. msr/mrs instructions are used to do this
and are allowed even if smefa64 is not present.

This register reports the configuration of the AArch64 Linux tagged
address ABI, part of which is the memory tagging (MTE) settings.

It will always be present in core files because even without MTE, there
are parts of the tagged address ABI that can be configured (these parts
use the Top Byte Ignore feature).

I missed adding this when I previously worked on MTE support. Until now
you could read memory tags from a core file but not this register.

`foldAttributesIntoMap` is a helper function that folds constant
`OpFoldResult` into an affine map. This commit moves the function from
the affine dialect to `AffineMap.h`, so that it can be used without
depending on the affine dialect.

Though I doubt that many people will land here directly, I thought it
odd that we didn't have one we can at least reference in response to questions.

The intro I've copied from the programmer's reference and added a simple
example. Then some links to resources and tools, which is the main
reason to have this page.

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