1. Added a conversion for `vector.deinterleave` to the `VectorToSPIRV`
pass.
2. Added LIT tests for the new conversion.

---------

Co-authored-by: Jakub Kuderski <kubakuderski@gmail.com>

The setAtom call introduced by e17bc023
was due to my misunderstanding of flushPendingLabels
(see https://discourse.llvm.org/t/mc-removing-aligned-bundling-support/79518).

When evaluating `.quad x-y`,
MCExpr.cpp:AttemptToFoldSymbolOffsetDifference gives different results
at parse time and layout time because the `if (FA->getAtom() ==
FB.getAtom())` condition in isSymbolRefDifferenceFullyResolvedImpl only
works when `setAtom` with a non-null pointer has been called. Calling
setAtom in flushPendingLabels does not help anything.

If NV == 0, nothing interesting happens after the "if" statement.  We
should just "continue" to the next value site.

While I am at it, this patch migrates a use of getValueForSite to
getValueArrayForSite.

The file was added to MLIRBindingsPythonCoreNoCAPI but objects weren't.

Signed-off-by: Jacques Pienaar <jpienaar@google.com>

This patch is a collection of one-liner migrations to
getValueArrayForSite.

See Buildbot failures:

- https://lab.llvm.org/buildbot/#/builders/78/builds/13
- https://lab.llvm.org/buildbot/#/builders/182/builds/7

Extra test cases that caused revert of
https://github.com/llvm/llvm-project/pull/92555

Fixes: #94769

This reverts commit 70510733.

The following code is now incorrectly rejected.

```
% cat neon.c
#include <arm_neon.h>
__attribute__((target("arch=armv8-a")))
uint64x2_t foo(uint64x2_t a, uint64x2_t b) {
  return veorq_u64(a, b);
}
% newclang --target=aarch64-linux-gnu -c neon.c
neon.c:5:10: error: always_inline function 'veorq_u64' requires target feature 'outline-atomics', but would be inlined into function 'foo' that is compiled without support for 'outline-atomics'
    5 |   return veorq_u64(a, b);
      |          ^
1 error generated.
```

"+outline-atomics" seems misleading here.

…rective

Implement fixed-form line continuation when the continuation line is the
result of text produced by an #include or other preprocessing directive.
This accommodates the somewhat common practice of putting dummy or
actual arguments into a header file and #including it into several code
sites.

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

Accommodate operations with VALUE dummy arguments in the runtime support
for the REDUCE intrinsic function by splitting most entry points into
Reduce...Ref and Reduce...Value variants.

Further work will be needed in lowering to call the ...Value entry
points.

Without this patch, a typical traversal over the value data looks
like:

  uint32_t NV = Func.getNumValueDataForSite(VK, S);
std::unique_ptr<InstrProfValueData[]> VD = Func.getValueForSite(VK, S);
  for (uint32_t V = 0; V < NV; V++)
    Do something with VD[V].Value and/or VD[V].Count;

This patch adds getValueArrayForSite, which returns
ArrayRef<InstrProfValueData>, so we can do:

  for (const auto &V : Func.getValueArrayForSite(VK, S))
    Do something with V.Value and/or V.Count;

I'm planning to migrate the existing uses of getValueForSite to
getValueArrayForSite in follow-up patches and remove getValueForSite
and getNumValueDataForSite.

An assumed-rank dummy argument is not an acceptable MOLD argument to
NULL(), whose result must have a known rank at compilation time.

When the very first statement of the executable part has syntax errors,
it's not at all obvious whether the error messages that are reported to
the user should be those from its failure to be the last statement of
the specification part or its failure to be the first executable
statement when both failures are at the same character in the cooked
character stream. Fortran makes this problem more exciting by allowing
statement function definitions look a lot like several executable
statements.

The current error recovery scheme for declaration constructs depends on
a look-ahead test to see whether the failed construct is actually the
first executable statement. This works fine when the first executable
statement is not in error, but should also allow for some error cases
that begin with the tokens of an executable statement.

This can obviously still go wrong for declaration constructs that are
unparseable and also have ambiguity in their leading tokens with
executable statements, but that seems to be a less likely case.

Also improves error recovery for parenthesized items.

This patch adds armv7m and armv8m runtimes to Fuchsia Clang toolchain
configuration.

Add the support to handle Linux kernel perf files. The functionality is
under option -kernel. Note that currently only main kernel (in vmlinux)
is handled: kernel modules are not handled.

---------

Co-authored-by: Han Shen <shenhan@google.com>

We currently receive a warning on all Github Actions workflows that use
`setup-python`, since they all use v4 of the action, which uses the
deprecated Node.js 16. This PR upgrades the action in all places to v5,
which uses Node.js 20 (see [setup-python release
page](https://github.com/actions/setup-python/releases/tag/v5.0.0))

Reverts llvm/llvm-project#73980

This broke static hwasan binaries in Android, for some reason the
fixed_shadow_base branch gets taken

When an uninstrumented libatomic is used with a TSan instrumented
memcpy, TSan may report a data race in circumstances where writes are
arguably safe.

This occurs because __atomic_compare_exchange won't be instrumented in
an uninstrumented libatomic, so TSan doesn't know that the subsequent
memcpy is race-free.

On the other hand, pthread_mutex_(un)lock will be intercepted by TSan,
meaning an uninstrumented libatomic will not report this false-positive.

pthread_mutexes also may try a number of different strategies to acquire
the lock, which may bound the amount of time a thread has to wait for a
lock during contention.

While pthread_mutex_lock has a larger overhead (due to the function call
and some dispatching), a dispatch to libatomic already predicates a lack
of performance guarantees.

Part of #95250.

The default debug info format for newer versions of Darwin is DWARF 5.

https://developer.apple.com/documentation/xcode-release-notes/xcode-16-release-notes

rdar://110925733

(relanding 8f6acd97 with the bridgeOS platform check removed)

If a function requires any streaming-mode change, the vector granule
value must be stored to the stack and unwind info must also describe the
save of VG to this location.

This patch adds VG to the list of callee-saved registers and increases
the
callee-saved stack size if the function requires streaming-mode changes.
A new type is added to RegPairInfo, which is also used to skip restoring
the register used to spill the VG value in the epilogue.

See
https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst

This reverts commit 00798354.

Causes crashes, see comments on https://github.com/llvm/llvm-project/pull/92555.

Support case-insensitive regex matches for
`SBTarget::FindGlobalFunctions` and `SBTarget::FindGlobalVariables`.

commonBits has been deprecated since:

  commit d8229e2f
  Author: Jay Foad <jay.foad@amd.com>
  Date:   Wed May 10 16:50:33 2023 +0100

This patch adds a new set of statistics to llvm-dwarfdump that provide
additional information about .debug_line regarding the number of bytes
covered by the line table (and how many of those are covered by line 0
entries), and the number of entries within the table and how many of
those are is_stmt, unique, or unique and non-line-0 (where "uniqueness"
is based on file, line, and column only).

Collectively these give a little more insight into the state of debug
line information, rather than variables (as most of the dwarfdump
statistics are currently oriented towards). I've added all of the stats
that were useful to some degree, but I think the most generally useful
stat is "unique line entries", since it gives the most straightforward
indication of regressions, i.e. when the number goes down it means that
fewer source lines are reachable in the program.

Create additional helper functions for the ValueObject class, for:
  - returning the value as an APSInt or APFloat
  - additional type casting options
  - additional ways to create ValueObjects from various types of data
  - dereferencing a ValueObject

These helper functions are needed for implementing the Data Inspection
Language, described in
https://discourse.llvm.org/t/rfc-data-inspection-language/69893

LLVM's Vector Predication Intrinsics require an explicit vector length
parameter:
https://llvm.org/docs/LangRef.html#vector-predication-intrinsics.

For a scalable vector type, this should be caculated as VectorScaleOp
multiplied by base vector length, e.g.: for <[4]xf32> we should return:
vscale * 4.

Ahead of https://github.com/llvm/llvm-project/pull/94242 and as
requested in the technical call, I am adding a couple of tests for
pointer components that I would like to make sure are covered.

The custom lowering converts to f32, splats as f32, then narrows the
vector to bf16. None of that requires Zvfhmin.

Add new bf16 test files without Zvfh/Zvfmin in their RUN lines. I will
remove the bf16 tests from other files in a follow up patch.

This isn't used by clang and isn't in the rvv-intrinsic-doc.

The instruction requires Zvfh.

If the F register passed to the instruction isn't nan-boxed correctly,
the instruction will generate the wrong nan. So the instruction isn't a
generic move FPR16 to vector register instruction.

MLIR's LLVM dialect does not internally support debug records, only
converting to/from debug intrinsics. To smooth the transition from
intrinsics to records, there is a step prior to IR->MLIR translation
that switches the IR module to intrinsic-form; this patch adds the
equivalent conversion to record-form at MLIR->IR translation.

This is a partial reapply of
https://github.com/llvm/llvm-project/pull/95098 which can be landed once
the flang frontend has been updated by
https://github.com/llvm/llvm-project/pull/95306. This is the counterpart
to the earlier patch https://github.com/llvm/llvm-project/pull/89735
which handled the IR->MLIR conversion.

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