The logic for chained basic arithmetic operations in the `arith` dialect
was using `getInt()` on `IntegerAttr`. This is a problem for very large
integers. Specifically, in
https://github.com/llvm/llvm-project/issues/64774 the following
assertion failed:

```
Assertion failed: (getSignificantBits() <= 64 && "Too many bits for int64_t"), function getSExtValue, file APInt.h, line 1510.
```

According to a comment on `getInt()`, calls to `getInt()` should be
replaced by `getValue()`:

https://github.com/llvm/llvm-project/blob/ab6a66dbec61654d0962f6abf6d6c5b776937584/mlir/include/mlir/IR/BuiltinAttributes.td#L707-L708

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

 by
doing such a replacement.

---------

Co-authored-by: Markus Böck <markus.boeck02@gmail.com>

RISC-V supports mapping syms for code that encode the exact ISA for
which the code is valid. They have the form `$x<ISA>` where `<ISA>` is
the textual encoding of an ISA specification.

BOLT currently doesn't recognize these mapping symbols causing many
binaries compiled with newer versions of GCC (which emits them) to not
be properly processed. This patch makes sure BOLT recognizes them as
code markers.

Note that LLVM does not emit these kinds of mapping symbols yet so the
test is based on a binary produced by GCC.

This reverts commit 47e36266e93de9c34ba3028951a58124864bb2b4.

This change broke some arm8/arm7 build bots because int and void * have
the same size.

Co-authored-by: einvbri <vince.a.bridgers@ericsson.com>

This makes these match the behaviour of optional attributes (which are
omitted when they are their default value of none). This allows for
concise assembly formats without a custom printer.

An extra print of " " is also removed, this does change any existing
uses of oilists, but if the parameter before the oilist is optional,
that would previously add an extra space.

This #68694 + some fixes for the MLIR Python tests, unfortunately GitHub
does not allow re-opening PRs 😕

Adds the Img2Col transformation for the fhwc channel ordering in a
Conv2D. Because of how the channel ordering affects the matrix
dimensions in the flattened filter this results in a slightly different
implementation of the actual "matrix multiplication". Instead of doing a
regular row-column dot-product this arrangement requires a row-row dot
product, otherwise the filter matrix would first need to be transposed.

Adds a lit test to the transform dialect to check the semantics of the
optimization are correct.

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

An IR sample in LangRef had a misplaced comment delimiter.

When defining a multi-line string in tblgen, the output in the Markdown
file currently contains too much whitespace and newlines for Hugo's
Markdown parser. For example, for `arith.addui_extended` the tblgen
```tblgen
let summary = [{
  extended unsigned integer addition operation returning sum and overflow bit
}];
```
is currently converted to
```markdown
_
    extended unsigned integer addition operation returning sum and overflow bit
  _
```
which causes the text to not be italicized (as can be seen at
https://mlir.llvm.org/docs/Dialects/ArithOps/#arithaddui_extended-arithadduiextendedop).
After this PR, the output becomes
```
_Extended unsigned integer addition operation returning sum and overflow bit_
```

The last use of identity was removed by:

  commit 388b8c16
  Author: Benjamin Kramer <benny.kra@googlemail.com>
  Date:   Wed Jan 25 01:38:28 2023 +0100

While I am at it, this patch teaches IndexedMap.h to include
identity.h as it is relying on transitive includes via
llvm/ADT/STLExtras.h.

The optimization in CodeGenPrepare, where GEPs are unmerged across
indirect branches must respect the types of both GEPs and their sizes
when adjusting the indices.

The sample here shows the bug:

https://godbolt.org/z/8e9o5sYPP

The value `%elementValuePtr` addresses the second field of the
`%struct.Blub`. It is therefore a GEP with index 1 and type i8.
The value `%nextArrayElement` addresses the next array element. It is
therefore a GEP with index 1 and type `%struct.Blub`.

Both values point to completely different addresses, even if the indices
are the same, due to the types being different.
However, after CodeGenPrepare has run, `%nextArrayElement` is a bitcast
from `%elementValuePtr`, meaning both were treated as equal.

The cause for this is that the unmerging optimization does not take
types into consideration.
It sees both GEPs have `%currentArrayElement` as source operand and
therefore tries to rewrite `%nextArrayElement` in terms of
`%elementValuePtr`.
It changes the index to the difference of the two GEPs. As both indices
are `1`, the difference is `0`. As the indices are `0` the GEP is later
replaced with a simple bitcast in CodeGenPrepare.

Before adjusting the indices, the types of the GEPs would have to be
aligned and the indices scaled accordingly for the optimization to be
correct.
Due to the size of the struct being `16` and the `%elementValuePtr`
pointing to offset `1`, the correct index for the unmerged
`%nextArrayElement` would be 15.

I assume this bug emerged from the opaque pointer change as GEPs like
`%elementValuePtr` that access the struct field based of type i8 did not
naturally occur before.

In light of future migration to ptradd, simply not performing the
optimization if the types mismatch should be sufficient.

This reverts commit b9b8fc48.

This uses a function defined in LLVM's config-ix inside clang.
config-ix is a non-exported cmake module, so this is a layering
violation.

This fixes erorrs like these:

llvm-project/llvm/tools/llvm-remarkutil/RemarkCounter.h:90:14: error: call to deleted constructor of 'llvm::Error'
      return E;
             ^
llvm-project/llvm/include/llvm/Support/Error.h:189:3: note: 'Error' has been explicitly marked deleted here
  Error(const Error &Other) = delete;
  ^
llvm-project/llvm/include/llvm/Support/Error.h:496:18: note: passing argument to parameter 'Err' here
  Expected(Error Err)
                 ^

Closes #68958.

The byte strides in zero and one element array descriptor may not be
perfect multiple of the element size and previous and extents.

IsContiguous and its CFI equivalent should still return true for such
arrays (Fortran 2018 standards says in 8.5.7 that an array is not
contiguous if it has two or more elements and ....).

The high time complexity of cache-directed sort is a real issue and is not
appropriate as the default, at least for now
(https://github.com/llvm/llvm-project/pull/68638#issuecomment-1760918891).

Prefer to use .empty() instead of checking size() == 0.

Added VectorOps support for ArmSVE in BUILD.bazel
Added BasicPtxBuilderInterface support for NVVM in build.bazel

SwapByteOrder.h doesn't use anything from <cstddef>.

Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces support::{big,little,native} with
llvm::endianness::{big,little,native}.

Note that llvm::support::endianness has been renamed to
llvm::endianness.  This patch replaces support::endianness::little
with llvm::endianness::little.

While I am at it, this patch removes "using namespace llvm;".

This PR is following what https://reviews.llvm.org/D134783 does for
quardword CAS.

svsel(pture, x, y) => x. depend on D121792
Reviewed By: paulwalker-arm, david-arm

Fully compose `affine.apply` ops before adding them to the underlying
`FlatLinearConstraints`. This works around a limitation of
`FlatLinearConstraints`, which cannot deduce a constant bound if it
involves two identical local variables.

Details for future improvements of `FlatLinearConstraints`: The
constraint set infrastructure fails to compute a constant bound of -8
for the first variable.
```
Domain: 0, Range: 1, Symbols: 4, Locals: 2
8 constraints
(None    None    None    None    None    Local    Local    const)
 1    -1    0    0    0    0    0    0    = 0
 0    1    -1    1    0    0    0    0    = 0
 0    0    1    0    0    0    -16    0    = 0
 0    0    0    1    0    -16    0    -8    = 0
 0    0    0    0    -1    0    32    31    >= 0
 0    0    0    0    1    0    -32    0    >= 0
 0    0    0    0    -1    32    0    31    >= 0
 0    0    0    0    1    -32    0    0    >= 0
```

`R_PPC64_GOT_PCREL34` is generated for pwr10+.

For consistency with other predicates, rename:
  * allDimsScalableVectorTypePred -> IsVectorTypeWithAllDimsScalablePred
  * IsScalableVectorTypePred -> IsVectorTypeWithAnyDimScalablePred

This reverts commit 6668d149.

It doesn't seem to do anything useful beyond what the C library header
is doing, so there's no purpose in having one.

PR#66035 introduced a test failure that causes windows build bots to
fail. These unit tests shouldn't be running on Windows.

Summary:

Test Plan:

Reviewers:

Subscribers:

Tasks:

Tags:

BasicPtxBuilder includes NVVMDialect and vice versa. Cmake appereantly
forgives that, but this causes bazel build fails. This PR aims to fix
that

Implements for sv39 and sv48 VMA layout.

Userspace only has access to the bottom half of vma range. The top half
is used by kernel. There is no dedicated vsyscall or heap segment.
PIE program is allocated to start at TASK_SIZE/3*2. Maximum ASLR is
ARCH_MMAP_RND_BITS_MAX+PAGE_SHIFT=24+12=36 Loader, vdso and other
libraries are allocated below stack from the top.

Also change RestoreAddr to use 4 bits to accommodate MappingRiscv64_48

Reviewed by: MaskRay, dvyukov, asb, StephenFan, luismarques, jrtc27,
hiraditya, vitalybuka

Differential Revision: https://reviews.llvm.org/D145214



D145214 was reverted because one file was missing in the latest commit.
Luckily the file was there in the previous commit, probably the author
missed uploading that file with latest commit.

Co-authored-by: Alex Fan <alex.fan.q@gmail.com>

Using a wrapper (MergedVector) around vectors to avoid extra vector
allocations.
Plus a few edits in the comments.

Do the same as the Haiku GCC patches.

https://github.com/haikuports/haikuports/commit/46afdec05771d126eb6cb6c3b3deb957604617c4