* Add a LinAlg pass to convert 2D convolutions and quantized 2D
convolutions that have the `FHWC` filter channel ordering into a
transpose followed by 2D convolutions that have the `HWCF` channel
ordering.

* Add a lit test to check the semantics of the transformation are
correct for both quantized and unquantized variants.

Signed-off-by: Jack Frankland <jack.frankland@arm.com>

...and follow ups.

As it has caused test failures on Linux Arm and AArch64:
https://lab.llvm.org/buildbot/#/builders/96/builds/49126
https://lab.llvm.org/buildbot/#/builders/17/builds/45824

```
  lldb-shell :: Subprocess/clone-follow-child-wp.test
  lldb-shell :: Subprocess/fork-follow-child-wp.test
  lldb-shell :: Subprocess/vfork-follow-child-wp.test
```

This reverts commit a6c62bf1,
commit a0a1ff3a and commit
fc6b7252.

Launch/stopped ordering was fixed by bd8f1068
but the Windows on Arm bot wasn't running at the time it landed.

The UTC output has changes slightly, regenerate tests to minimize
future diff.

This is needed after 225648e9

Co-authored-by: PaperChalice <example@example.com>

A splat packed constant can be folded as an inline immediate but it
shall use opsel. On gfx940 this code path can be skipped due to HW bug
workaround and then it may be folded w/o opsel which is a bug. Fixed.

The indexed compare fold converts comparisons of GEPs with same
(indirect) base into comparisons of offset. Currently, it only supports
GEPs with the same source element type.

This change makes the transform operate on offsets instead, which
removes the type dependence. To keep closer to the scope of the original
implementation, this keeps the limitation that we should only have at
most one variable index per GEP.

This addresses the main regression from
https://github.com/llvm/llvm-project/pull/68882.

TBH I have some doubts that this is really a useful transform (at least
for the case where there are extra pointer users, so we have to
rematerialize pointers at some point). I can only assume it exists for a
reason...

Store the ReverseChildren using node indices instead of node pointers.
This avoids some more hash table lookups.

I've also increased the size of the SmallVector from 2 to 4. As the
indices are half as large as the pointers (on 64bit) this keeps memory
usage the same as before. I've found the larger SmallVector to perform a
bit better.

This reverts commit 344b5346.
92b821f2 relanded in 04072485.

This reverts commit aaae104e.

This reverts commit 934efd2c.

This relands commit 1449b349.

This build system fix was reverted as the underlying patch that required
the fix got reverted due to test failures on Darwin. The test failures
have since been fixed and the patch has relanded, so we need support in
Bazel again.

This PR suggests a way to fix
https://github.com/llvm/llvm-project/issues/70418. It now throws an
error if the `index` operand for `memref.dim` is out of bounds. Catching
it in the verifier was not possible because the constant value is not
yet available at that point. Unfortunately, the error is not very
descriptive since it was only possible to propagate boolean up.

Follow up to
https://github.com/llvm/llvm-project/pull/72763#discussion_r1398277962.

### Summary
- Add unit tests for raising excepts in `nextafter`. 
- Fixed a bug in testing code for `nexttoward`.  

cc: @lntue

-frtti is not a CC1 option. We just need to check -fno-rtti.

1. Remove unused variables, e.g X86Subtarget object in performCustomAdjustments
2. Define checkVEXInstPredicate directly instead of generating it b/c
   the function is small and it's unlikely we have more instructions to
   check the predicate in the future
3. Check the tables are sorted only once for each function
4. Remove some blanks and clang-format code

This reverts commit ea5de602.

This patch was reverted as it broke a test on x86_64 Darwin due to the
symbol naming being different between platforms. As Darwin isn't a
supported platform for executing snippets for llvm-exegesis, we can just
disable the test to fix the issue.

Using IR test to make it easier to compare with the SelectionDAG test
output. The constant operands otherwise make it harder to understand.

b/c VEX prefix can not encode R16-R31.

- Support non-member functions and callable objects for size and data().
We previously tried to (badly) pick the best overload ourselves, in a
way that would only support member functions. We now leave clang
construct an unresolved member expression and call that, properly
performing overload resolution with callable objects and static
functions, consistent with the logic for `get` calls for structured
bindings.
- Support UDLs as message expression.
- Add tests and mark CWG2798 as resolved

CodeSize was designed to used as the 3rd isel sorting tie-breaker.
From observation, it has no impact on X86 ISEL.

BPF upstream reported that JSET insn is not supported in inline asm
([1]). BPF_JSET insn is part of BPF ISA so let us add asm support for it
now.

[1]
https://lore.kernel.org/bpf/2e8a1584-a289-4b2e-800c-8b463e734bcb@linux.dev/

Not use r16-r31 with 'q','r','l' constraint for backward compatibility

… loop bound.

Found while running libc++'s test suite with MSVC's STL.

MSVC has a level 1 "warning C5101: use of preprocessor directive in
function-like macro argument list is undefined behavior". I don't know
why Clang doesn't complain about this.

There are some formatting tests which densely interleave preprocessor
directives within function-like macros, and they would need invasive
changes. For now, I'm just skipping those tests.

However, a few tests were only slightly affected, and I was able to add
a new test macro `TEST_IF_AIX` to make them portable.

This is part of a stack of PRs to add support for symbolizer
markup in linux.

You can check the symbolizer markup specification at:
https://llvm.org/docs/SymbolizerMarkupFormat.html

Reviewers: vitalybuka, PiJoules

Reviewed By: vitalybuka

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

step closer towards moving all type related methods into encoding and/or
sparse tensor type class

Found while running libc++'s test suite with MSVC's STL.

MSVC's STL rejects `allocator<const T>`. This may or may not be
justified by the current Standardese (it was bogus in the C++03 era),
but it's how we reject usage like `vector<const T>`.

A bunch of `mdspan` tests are failing for us because some centralized
machinery is using `allocator<const T>`. Testing that `mdspan` and its
associated types work properly with `const T` is good and necessary, but
directly allocating `const T` is what's a problem for MSVC's STL. I'd
like to ask for a very targeted change here that preserves all of the
test coverage but changes how `ElementPool` interacts with `allocator`.

This intentionally leaves `ElementPool::get_ptr()` returning `T*`
(pointer-to-possibly-const), so there's no externally visible
difference.

Most libc_support_library calls are for header-only libraries, but there
are a few that have .cpp files. This patch adds the same base copts to
these that libc_function already has.

Following the discussions in this thread,
https://discourse.llvm.org/t/some-question-on-the-semantics-of-the-arith-dialect/74861

,
here are some updates to the documented semantics of Arith.
Added are clarifications on poison behaviour, UBs, overflow semantics,
and the underlying two's complement representation used for integers

Co-authored-by: kuhar <jakubk@openxla.org>
Co-authored-by: math-fehr <mathieu.fehr@gmail.com>

The combine was implicitly assuming that the index on the outer
insert_subvector meant the same thing when the source was switched to be
the index of the inner insert_subvector. This is not true if the
innermost sub-vector is fixed, and the outer subvector is scalable.

I could do a less restrictive fix here - i.e. allow the case where the
scalability of the subvectors are the same - but there's no test
coverage which shows this transform actually has profit. Given that, go
for the simplest fix.

Moves sanitizer symbolizer code that is specific for
fuchsia into its own _fuchsia.cpp file.
This is preparation to enable symbolizer markup in
linux.

Reviewers: PiJoules, petrhosek, vitalybuka

Reviewed By: PiJoules, vitalybuka

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