As per the Cortex-A510 software optimization guide, the latency of a
fcsel should be 3 not 4. It would previously get the latency from
WriteF.

Since https://github.com/ARM-software/acle/pull/276 the ACLE
defines attributes to better describe the use of a given SME state.

Previously the attributes merely described the possibility of it being
'shared' or 'preserved', whereas the new attributes have more semantics
and also describe how the data flows through the program.

For ZT0 we already had to add new LLVM IR attributes:
* aarch64_new_zt0
* aarch64_in_zt0
* aarch64_out_zt0
* aarch64_inout_zt0
* aarch64_preserves_zt0

We have now done the same for ZA, such that we add:
* aarch64_new_za       (previously `aarch64_pstate_za_new`)
* aarch64_in_za (more specific variation of `aarch64_pstate_za_shared`)
* aarch64_out_za (more specific variation of `aarch64_pstate_za_shared`)
* aarch64_inout_za (more specific variation of
`aarch64_pstate_za_shared`)
* aarch64_preserves_za (previously `aarch64_pstate_za_shared,
aarch64_pstate_za_preserved`)

This explicitly removes 'pstate' from the name, because with SME2 and
the new ACLE attributes there is a difference between "sharing ZA"
(sharing
the ZA matrix register with the caller) and "sharing PSTATE.ZA" (sharing
either the ZA or ZT0 register, both part of PSTATE.ZA with the caller).

Summary:
The old `s_memtime` instruction was supported until the GFX10
architecture. Although this instruction has a higher latency than the
new shader counter, it's much more usable as a processor clock as it is
a full 64-bit counter. The new shader counter is only a 20-bit counter,
which makes it difficult to use as a standard cycle counter as it will
overflow in a few milliseconds. This patch suggests preferring
`s_memtime` for this instrinsic if it is still available.

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

Split out from #78417.

Reviewers: topperc, asb, kito-cheng

Reviewed By: asb

Pull Request: https://github.com/llvm/llvm-project/pull/79248

Implements P2652R2 <https://wg21.link/P2652R2>:
- https://eel.is/c++draft/allocator.requirements.general
- https://eel.is/c++draft/memory.syn
- https://eel.is/c++draft/allocator.traits.general
- https://eel.is/c++draft/allocator.traits.members
- https://eel.is/c++draft/diff.cpp20.concepts
- https://eel.is/c++draft/diff.cpp20.utilities



---------

Co-authored-by: Zingam <zingam@outlook.com>

We are replacing with a wider increment. If both OrigInc and
IsomorphicInc are NUW/NSW, then we can preserve them on the wider
increment; the narrower IsomorphicInc would wrap before the wider
OrigInc, so the replacement won't make IsomorphicInc's uses more
poisonous.

PR: https://github.com/llvm/llvm-project/pull/79512

When the markdown link renders the line gets a lot shorter.

According to its doc-comment `isImplicit` is meant to return true if the
expression is an implicit location description (describes an object or part of
an object which has no location by computing the value from available program
state).

There's a brief entry for `DW_OP_LLVM_tag_offset` in the LangRef and there's
some info in the original commit fb9ce100.

From what I can tell it doesn't look like `DW_OP_LLVM_tag_offset` affects
whether or not the location is implicit; the opcode doesn't get included in the
final location description but instead is added as an attribute to the variable.

This was tripping an assertion in the latest application of the fix to #76545,
#78606, where an expression containing a `DW_OP_LLVM_tag_offset` is split into
a fragment (i.e., describe a part of the whole variable).

This updates clang's target defines to include the ACLE changes covering
the FEAT_PAuth_LR architecture extension.
The changes include:
* The new `__ARM_FEATURE_PAUTH_LR` feature macro, which is set to 1 when
  FEAT_PAuth_LR is available in the target.
* A new bit field for the existing `__ARM_FEATURE_PAC_DEFAULT` macro,
  indicating the use of PC as a diversifier for Pointer Authentication
  (from -mbranch-protection=pac-ret+pc).

The approved changes to the ACLE spec can be found here:
https://github.com/ARM-software/acle/pull/292

The verifiers are currently very strict: requiring intrinsic operations
to be used only in cases where the Fortran standard permits the
intrinsic to be used.

There have now been a lot of cases where these verifiers have caused
bugs in corner cases. In a recent ticket, @jeanPerier pointed out that
it could be useful for future optimizations if somewhat invalid uses of
these operations could be allowed in dead code. See this comment:
https://github.com/llvm/llvm-project/issues/79995#issuecomment-1918118234

In response to all of this, I have decided to relax the intrinsic
operation verifiers. The intention is now to only disallow operation
uses that are likely to crash the compiler. Other checks are still
available under `-strict-intrinsic-verifier`.

The disadvantage of this approach is that IR can now represent intrinsic
invocations which are incorrect. The lowering and implementation of
these intrinsic functions is unlikely to do the right thing in all of
these cases, and as they should mostly be impossible to generate using
normal Fortran code, these edge cases will see very little testing,
before some new optimization causes them to become more common.

Fixes #79995

This patch replaces --num-repetitions with --min-instructions to make it
more clear that the value refers to the minimum number of instructions
in the final assembled snippet rather than the number of repetitions of
the snippet. This patch also refactors some llvm-exegesis internal
variable names to reflect the name change.

Fixes #76890.

This is a mess and needs to be cleaned up some day.

These two are intertwined enough so it doesn't really make sense to have
it standalone and hack around it by putting headers into both.

This adds a `func`, `call` and `return` operation to the EmitC dialect,
closely related to the corresponding operations of the Func dialect. In
contrast to the operations of the Func dialect, the EmitC operations do
not support multiple results. The `emitc.func` op features a
`specifiers` argument that for example allows, with corresponding
support in the emitter, to emit `inline static` functions.

Furthermore, this adds patterns and a pass to convert the Func dialect
to EmitC. A `func.func` op that is `private` is converted to
`emitc.func` with a `"static"` specifier.

Don't search for unnecessary libs when linking the shared lib. This
allows the test to run in chroot environment.

Derived type translation is proving expensive in modern fortran apps
with many big derived types with dozens of components and parents.

Extending the cache that prevent recursion is proving to have little
cost on apps with small derived types and significant gain (can divide
compile time by 2) on modern fortran apps.

It is legal since the cache lifetime is less than the MLIRContext
lifetime that owns the cached mlir::Type.

Doing so also exposed that the current caching was incorrect, the type
symbol is the same for kind parametrized derived types regardless of the
kind parameters. Instances with different kinds should lower to
different MLIR types. See added test.
Using the type scopes fixes the problem.

The greedy pattern rewrite driver has multiple "expensive checks" to
detect invalid rewrite pattern API usage. As part of these checks, it
computes fingerprints for every op that is in scope, and compares the
fingerprints before and after an attempted pattern application.

Until now, each computed fingerprint took into account all nested
operations. That is quite expensive because it walks the entire IR
subtree. It is also redundant in the expensive checks because we already
compute a fingerprint for every op.

This commit significantly improves the running time of the "expensive
checks" in the greedy pattern rewrite driver.

After iterating with the arm-ubuntu CI bot, I found the crash (a
std::bad_alloc exception being thrown) was caused by these two
entries when built on a 32-bit machine.  I probably have an assumption
about size_t being 64-bits in WatchpointAlgorithms and we have a
problem when it's actually 32-bits and we're dealing with a real
64-bit address.  All of the cases where the address can be represented
in the low 32-bits of the addr_t work correctly, so for now I'm
skipping these two unit tests when building lldb on a 32-bit host
until I can review that method and possibly switch to explicit
uin64_t's.
.

Go back to the original form of this file before I add temp
workaround.

[mlir] Use `create` instead of `createOrFold` for ConstantOp as folding has no effect (NFC) (#80129)

This aims to clean-up confusing uses of
builder.createOrFold<ConstantOp> since folding of constants fails.

Just delegate to the resulting expression.

We create them more often in C, so it's more likely to happen there.

Promoted and NF LZCNT/POPCNT/TZCNT were supported in #79954.
B/c null_frag is used in the patterns for these variants, tablgen can
not infer mayLoad = 1 for them.

This can be tested by MCA tests, which will be added after
-mcpu=<cpu_with_apx> is supported.

Initialize the first element to 0 and the second element to the value of
the subexpression.

Only the stage2-distribution target is built by default for the
stage2 distribution installation target. This means that we don't get a
BOLT optimized binary. This patch explicitly builds the
stage2-clang-bolt target before the distribution installation target so
that the clang binary is optimized before it gets installed.

The added test case would trigger the removed assertion.

CI bot crash when running this unittest.  The printfs aren't
printing into the CI log output.