The 8f208edd has removed the "unrecognized vendor-name" error, updated
the unittest accordingly.

* 80 columns
* Fix name of file (RISCVMoveMerger.cpp vs RISCVMoveMerge.cpp)
* `//===--` prefix rather than center-aligned text.

This was discussed somewhat in D148315. As it stands, we require in
RISCVISAInfo::parseArchString (used for e.g. -march parsing in Clang)
that extensions are given in the order of z, then s, then x prefixed
extensions (after the standard single-letter extensions). However, we
recently (in D148315) moved to that order from z/x/s as the canonical
ordering was changed in the spec. In addition, recent GCC seems to
require z* extensions before s*.

My recollection of the history here is that we thought keeping -march as
close to the rules for ISA naming strings as possible would simplify
things, as there's an existing spec to point to. My feeling is that now
we've had incompatible changes, and an incompatibility with GCC there's
no real benefit to sticking to this restriction, and it risks making it
much more painful than it needs to be to copy a -march= string between
GCC and Clang.

This patch removes all ordering restrictions so you can freely mix x/s/z
extensions.

To be very explicit, this doesn't change our behaviour when emitting a
canonically ordered extension string (e.g. in build attributes). We of
course sort according to the canonical order (as we understand it) in
that case.

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

A small refactor to add more `_Common` feature sets for GFX8+.

Reviewed By: foad

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

An .ARM.attributes section is divided into subsections, each labelled
with a vendor name. There is one standardised vendor name, which must
be used for all attributes that affect compatibility. Subsections
labelled with other vendor names can be used for optimisation
purposes, but it has to be safe for an object file consumer to ignore
them if it doesn't recognise the vendor name.

LLD currently terminates parsing of the whole attributes section as
soon as it encounters a subsection with a vendor name it doesn't
recognise (which is anything other than the standard one). This can
prevent it from detecting compatibility issues, if a standard
subsection followed the vendor-specific one.

This patch modifies the attribute parser so that unrecognised vendor
subsections are silently skipped, and the subsections beyond them are
still processed.

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

As discussed in the RFC at
https://discourse.llvm.org/t/rfc-proposing-a-code-owner-for-the-experimental-constexpr-interpreter/71514

This patch adds support for vector subscripted assignment left-hand
side. It does not yet add support for the cases where the LHS must be
saved because its evaluation could be impacted by the assignment.

The implementation adds an hlfir::ElementalOpInterface to share the
elemental inlining utility and some other tools between
hlfir::ElementalOp and hlfir::ElelemntalAddrOp.

It adds generateYieldedLHS() to allow retrieving the LHS value
in lowering, whether or not it is vector subscripted. If it is vector
subscripted, this utility creates a loop nest iterating over the
elements and returns the address of an element.

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

Extra tests with different GEP step sizes for D152730.

This reverts commit 173df3dd.

Looks like this wasn't as innocent as it seemed:
https://lab.llvm.org/buildbot#builders/38/builds/12982

Use dyn_cast_if_present instead of _or_null, use decomposition decls,
and a few other minor things.

We can do that and we already checked that they aren't nullopt before.

This showed up in https://reviews.llvm.org/D153308

Reviewed By: courbet, nikic

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

Previously lldb was using arrays of size kMaxRegisterByteSize to handle
registers. This was set to 256 because the largest possible register
we support is Arm's scalable vectors (SVE) which can be up to 256 bytes long.

This means for most operations aside from SVE, we're wasting 192 bytes
of it. Which is ok given that we don't have to pay the cost of a heap
alocation and 256 bytes isn't all that much overall.

With the introduction of the Arm Scalable Matrix extension there is a new
array storage register, ZA. This register is essentially a square made up of
SVE vectors. Therefore ZA could be up to 64kb in size.

https://developer.arm.com/documentation/ddi0616/latest/

"The Effective Streaming SVE vector length, SVL, is a power of two in the range 128 to 2048 bits inclusive."

"The ZA storage is architectural register state consisting of a two-dimensional ZA array of [SVLB × SVLB] bytes."

99% of operations will never touch ZA and making every stack frame 64kb+ just
for that slim chance is a bad idea.

Instead I'm switching register handling to use SmallVector with a stack allocation
size of kTypicalRegisterByteSize. kMaxRegisterByteSize will be used in places
where we can't predict the size of register we're reading (in the GDB remote client).

The result is that the 99% of small register operations can use the stack
as before and the actual ZA operations will move to the heap as needed.

I tested this by first working out -wframe-larger-than values for all the
libraries using the arrays previously. With this change I was able to increase
kMaxRegisterByteSize to 256*256 without hitting those limits. With the
exception of the GDB server which needs to use a max size buffer.

Reviewed By: JDevlieghere

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

This commit changes the 'llvm.switch' parsing to not silently fail when
it encounters superfluous commas in the case list.

Reviewed By: gysit

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

See

https://llvm.org/docs/CodingStandards.html#use-namespace-qualifiers-to-implement-previously-declared-functions

Thank you to MaskRay for pointing this out on

https://reviews.llvm.org/D153006

Reviewed By: xazax.hun

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

Fix #63007

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

Remove DAGISel checks on calling conventions. GlobalISel doesn't have
these checks either and we prefer it that way (see D152794).

Add a simple test like the one introduced in D117479 for GlobalISel.

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

after 1b66840f, FindTarget will report multiple refs with the same
location, make the sort order of the refs deterministic in
FindTargetTests.

This fixes #62068.

After 8d1de7b3 the following issue appeared:
```
$ ./bin/lldb /tmp/test.o
(lldb) target create "/tmp/test.o"
Current executable set to '/tmp/test.o' (aarch64).
(lldb) platform process launch -s
error: Cannot launch '': Nothing to launch
```

Previously would call target->GetRunArguments when there were no extra
arguments, so we could find out what target.run-args might be.

Once that change started relying on the first arg being the exe,
the fact that that call clears the existing argument list caused the bug.

Instead, have it set a local arg list and append that to the existing
one. Which in this case will just contain the exe name.

Since there's no existing tests for this command I've added a new file
that covers enough to check this issue.

Reviewed By: labath

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

We currently preserve the nsw flag when negating scales, which is
incorrect for INT_MIN.

However, just dropping the NSW flag in this case makes BasicAA
behavior unreliable and asymmetric, because we may or may not
drop the NSW flag depending on which side gets subtracted.

Instead, leave the Scale alone and add an additional IsNegated flag,
which indicates that the whole VarIndex should be interpreted as a
subtraction. This allows us to retain the NSW flag.

When accumulating the offset range, we need to use subtraction
instead of adding for IsNegated indices. Everything else works on
the absolute value of the scale, so the negation does not matter
there.

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

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

Reviewed By: dcaballe, Dinistro

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

D149522 introduced target features to LinkGraph. However, to avoid a
public dependency on MC, the features were stored in a std::vector
instead of using SubtargetFeatures directly.

Since SubtargetFeatures was moved from MC to TargetParser (D150549), we
can now use it directly to store the features. This patch implements
that and removes the (private) dependency on MC.

Reviewed By: lhames

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

This revision adds comdat support to functions. Additionally,
it ensures only comdats that have uses are imported/exported and
only non-empty global comdat operations are created.

Reviewed By: Dinistro

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

My last patch broke most of the builders that aren't currently running
at least Kernel 5.6 as there was a variable used later on inside a
region that required that kernel version. Also fixes a minor warning
left over from a bad merge.

This patch adds in support for using memory annotations in the
subprocess execution mode.

Revert "[mlir][Transform] Add support for mma.sync m16n8k16 f16 rewrite." and "[mlir][Transform] Introduce nvgpu transform extensions"

This reverts commit 40deed40.
and commit 1660f217.

The buildbot is broken, the two tests aren't passing.

This was leftover when I was working on the lit config while recomitting
a patch and never should've made it in tree.

This reverts commit c3e33720.

This has broken quite a few buildbots.

Add two new functions `createCond` and `createOrCond` that accept extra
arguments Arg and Arg/Arg2 respectively.

Reviewed By: efriedma

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

This patch adds memory annotation parsing to llvm-exegesis. The memory
annotations cannot be used currently, but this allows for using parsed
memory annotations within a FunctionExecutorImpl to set up a specified
execution environment.

I fixed compilation on 32-bit ARM earlier in the -Werror case using
preprocessor directives but forgot to update the unit tests that also
depend upon that value. This patch updates the unit tests as well as a
quick fix for the builders that were broken by the earlier patch.

In D152399, we calculate BPI->BFI in MachineFunctionSplit pass just to
use PSI->isFunctionHotInCallGraph, which is expensive. Instead, we can
implement this directly with MBFI.

Reviewer mentioned in the comment, that machine_size_opts already has
isFunctionColdInCallGraph, isFunctionHotInCallGraphNthPercentile, etc
implemented. These can be refactored and reused across MFS and machine
size opts.

This CL does this - it refactors out those internal static functions
into PSI as templated functions, so they can be accessed easily.

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

This revision is a part of a series of patches extending AddressSanitizer C++ container overflow detection capabilities by adding annotations, similar to those existing in `std::vector`, to `std::string` and `std::deque` collections. These changes allow ASan to detect cases when the instrumented program accesses memory which is internally allocated by the collection but is still not in-use (accesses before or after the stored elements for `std::deque`, or between the size and capacity bounds for `std::string`).

The motivation for the research and those changes was a bug, found by Trail of Bits, in a real code where an out-of-bounds read could happen as two strings were compared via a std::equals function that took `iter1_begin`, `iter1_end`, `iter2_begin` iterators (with a custom comparison function). When object `iter1` was longer than `iter2`, read out-of-bounds on `iter2` could happen. Container sanitization would detect it.

This revision introduces annotations for `std::deque`. Each chunk of the container can now be annotated using the `__sanitizer_annotate_double_ended_contiguous_container` function, which was added in the rG1c5ad6d2. Any attempt to access poisoned memory will trigger an ASan error. Although false negatives are rare, they are possible due to limitations in the ASan API, where a few (usually up to 7) bytes before the container may remain unpoisoned. There are no false positives in the same way as with `std::vector` annotations.

This patch only supports objects (deques) that use the standard allocator. However, it can be easily extended to support all allocators, as suggested in the D146815 revision.

Furthermore, the patch includes the addition of the `is_double_ended_contiguous_container_asan_correct` function to `libcxx/test/support/asan_testing.h`. This function can be used to verify whether a `std::deque` object has been correctly annotated.

Finally, the patch extends the unit tests to verify ASan annotations (added LIBCPP_ASSERTs).
If a program is compiled without ASan, all helper functions will be no-ops. In binaries with ASan, there is a negligible performance impact since the code from the change is only executed when the deque container changes in size and it’s proportional to the change. It is important to note that regardless of whether or not these changes are in use, every access to the container's memory is instrumented.

If you have any questions, please email:
- advenam.tacet@trailofbits.com
- disconnect3d@trailofbits.com

Reviewed By: #libc, philnik

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