This patch makes the display of member function calls more true to the user-written code by making use of the syntactical structure of the function calls.
This patch also changes the display of conventional value-based printing from arrow operator to dot operator.
This avoids the syntactical invalidness in notes previously caused by the display of & operator
(lack of parentheses and reference of rvalue)

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

Reviewed By: cjdb
Differential Revision: https://reviews.llvm.org/D151720

Add a missing check that ensures that ComplexDeinterleaving for reduction
is only analyzed for Real and Imaginary Instructions of the same type.

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

Partial progress towards replacing `CreateElementBitCast`, as it no
longer does what its name suggests. Either replace its uses with
`Address::withElementType()`, or remove them if no longer needed.

Reviewed By: barannikov88, nikic

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

X86's CMOV conversion transforms CMOV instructions into control flow between
blocks, meaning the value is computed by a PHI rather than a "real" machine
instruction. In instruction-referencing mode, we need to transfer the
instruction label between the old CMOV and the new PHI instruction to mark
where the variable value is computed.

There's an extra complication in that memory operands can be unfolded from the
CMOV and sunk into the new blocks -- the test checks both scenarios where the
instruction number has to hop between instructions.

This omission exposed by Dexter testing.

Reviewed By: Orlando

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

Move `AttributeMask` out of `llvm/IR/Attributes.h` to a new file
`llvm/IR/AttributeMask.h`.  After doing this we can remove the
`#include <bitset>` and `#include <set>` directives from `Attributes.h`.
Since there are many headers including `Attributes.h`, but not needing
the definition of `AttributeMask`, this causes unnecessary bloating of
the translation units and slows down compilation.

This commit adds in the include directive for `llvm/IR/AttributeMask.h`
to the handful of source files that need to see the definition.

This reduces the total number of preprocessing tokens across the LLVM
source files in lib from (roughly) 1,917,509,187 to 1,902,982,273 - a
reduction of ~0.76%. This should result in a small improvement in
compilation time.

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

This patch changes the handling of OpenMP to add the device attributes
to the canonical definitions when we encounter a non-canonical
definition. Previously, the following code would not work because it
would find the non-canonical definition first which would then not be
used anywhere else.

```
int x;
extern int x;
```

This patch now adds the attribute to both of them. This allows us to
perform the following operation if, for example, there were an
implementation of `stderr` on the device.

```
#include <stdio.h>

// List of libc symbols supported on the device.
extern FILE *stderr;
```

Unfortunately I cannot think of an equivalent solution to HIP / CUDA
device declarations as those are done with simple attributes. Attributes
themselves cannot be used to affect a definition once its canonical
definition has already been seen. Some help on that front would be
appreciated.

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

Reviewed By: ABataev

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

This reverts commit cc0fc358 due to a failure
reported on MacOS.

The CPSR registers ops of the instructions constructed in ExpandTMOV32BitImm
were marked as kill, instead of define. Best to use the pre-existing
t1CondCodeOp fn to construct CPSRs.

Reviewed By: simonwallis2

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

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

Add X86ISD::ANDNP handling to targetShrinkDemandedConstant as well, which allows us to replace a lot of truncated masks with (rematerializable) allones values

This reverts commit 8f208edd.

I completely missed the compiled unit test for ELFAttributeParser,
which also needs updating. I'll reland this change once I make further
fixes.

The way this is currently implemented the accumulated offsets can
end up having a different size, which causes unnecessary
complication for further extension of the code.

Don't strip pointer casts at the start and rely on
stripAndAccumulate to do any necessary stripping. It gracefully
handles different index sizes and will always retain the width of
the original pointer index type.

This is not NFC, but unlikely to make any practical difference.

Revert "[llvm-profdata] Refactoring Sample Profile Reader to increase FDO build speed using MD5 as key to Sample Profile map"

This reverts commit 12e9c7aa.

The commit has broken the buildbot, see comment https://reviews.llvm.org/D147740#4451540

Since LIBCXX_ENABLE_FILESYSTEM now truly represents whether the
platform supports a filesystem (as opposed to whether the <filesystem>
library is provided), we can provide a few additional classes from
the <filesystem> library even when the platform does not have support
for a filesystem. For example, this allows performing path manipulations
using std::filesystem::path even on platforms where there is no actual
filesystem.

rdar://107061236

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

Copy back the padded result to the original destination of the computation. This is important for bufferization, to ensure that the result of the computation does not suddenly materialize in a different buffer due to padding.

A `bufferization.copy_tensor` is inserted for every (unpadded) result. Such ops bufferize to memcpys, but they fold away, should the padding fold away.

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

This operation is a "copy" operation on tensors. It is guaranteed to bufferize to a memcpy. This is different from "tensor.insert_slice", which may fold away.

Note: There is a symmetry between certain tensor, bufferization and memref ops:
* `tensor.empty`, `bufferization.alloc_tensor`, `memref.alloc`
* (none), `bufferization.dealloc_tensor`, `memref.dealloc`
* `tensor.insert_slice`, `bufferization.copy_tensor`, `memref.copy`

Tensor ops can generally canonicalize/fold away, while bufferization dialect ops can be used when a certain side effect is expected to materialize; so they do not fold away.

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

Add an additional result handle to the op. This new handle is mapped to the newly allocated buffer.

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

* Use LinalgPaddingOptions instead of passing many parameters.
* Split function into two parts.

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

Also remove `LinalgPaddingPattern`, which has no uses. (There is a transform dialect op that is used for testing instead.)

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

The DWARF 5 specification says that:

> All other debugging information entries without a DW_AT_name attribute are
> excluded.

Clang started generating these variables for string literals, see D123534.

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

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