This patch updates the test for the MBB profile dump to include a
function that has multiple basic blocks so that we can test the
numbering of multiple basic blocks within an individual function.

Result must carry the polymorphic type information from the array.

Reviewed By: jeanPerier

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

An indexed LD1 instruction, or "ASIMD load, 1 element, one lane, B/H/S"
instruction that loads a value and inserts an element into a vector is
an expensive instruction. It has a latency of 8 on modern cores. We
generate an indexed LD1 when an insertelement instruction has a load as an
operand and this patch is recognising and makes indexed LD1 more expensive.

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

Throw an error when trying to compile with `-pg` on z/OS,
as the platform does not support `gprof`.

Reviewed By: cebowleratibm, MaskRay

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

This patch enables `-p` functionality into Clang on AIX and Linux
To create parity with GCC.

The purpose of the `-p` flag is similar to that of `-pg`, but the
results are analyzed with the `prof` tool as opposed to the `gprof` tool.
More details can be found in this RFC post:
https://discourse.llvm.org/t/rfc-add-p-driver-support-to-clang/66013?u=francii

On AIX, compiling with `-p` links against `mcrt0.o`
and produces a mon.out file analyzed with the `prof` tool,
while `-pg` links against `gcrt0.o` and produces a `gmon.out`file
analyzed with the `gprof` tool. The differences are therefore
only a concern when linking, so calling `-p` will push `-pg` to cc1.

An AIX test for `-p` already exists, and I recently
another test was added here:
https://github.com/llvm/llvm-project/commit/dc9846ce988b9ddfcbc42cd462d5d94b634b3161
As such, there is no AIX test case attached to this patch.

Reviewed By: daltenty

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

Alignment of an alloca in IR can be lower than the preferred alignment
on purpose, but this override essentially treats the preferred
alignment as the minimum alignment.

The patch changes this behavior to always use the specified
alignment. If alignment is not set explicitly in LLVM IR, it is set to
DL.getPrefTypeAlign(Ty) in computeAllocaDefaultAlign.

Tests are changed as well: explicit alignment is increased to match
the preferred alignment if it changes output, or omitted when it is
hard to determine the right value (e.g. for pointers, some structs, or
weird types).

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

We already have a EltSizeInBits variable

Pre-GFX10 A16 modifier would imply G16. From GFX10 and onwards there are
separate instructions for 16bit gradients. This fixes the condition for
selecting G16 opcodes. Also stop adding G16 flag to instructions that do not
use gradients for GFX10 onwards.

This function returns whether a block is nested inside of a loop. There
can be three kinds of loop:
  1) The block is nested inside of a LoopLikeOpInterface
  2) The block is nested inside another block which is in a loop
  3) There is a cycle in the control flow graph

This will be useful for Flang's stack arrays pass, which moves array
allocations from the heap to the stack. Special handling is needed when
allocations occur inside of loops to ensure additional stack space is
not allocated on each loop iteration.

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

This adds a release note that was accidentally dropped, and moves the
symbol from LLVM 16 to LLVM 17 in the module map.

Amends 0a51bc73

Extending the python generator:
- to generate C-compatibility symbols
- to generate macros

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

Suppresses "macro expansion producing 'defined' has undefined behavior"
due to the diagnostic triggering in WinBase.h (a system header file).

__builtin_amdgcn_fmed3 is unused since the actual builtins are
defined by Clang and have a floating point type suffix, h or f.

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

Fixes #58747

This commit moves the importing logic of access group metadata into the
loop annotation importer. These two metadata imports can be grouped
because access groups are only used in combination with
`llvm.loop.parallel_accesses`.

As a nice side effect, this commit decouples the LoopAnnotationImporter
from the ModuleImport class.

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

indexes are all constant

Some extra cases that were not covered in 6da0184b.

Reviewed By: springerm

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

- Specify that the .clang-tidy file is in YAML format.
- Document the options that may be used in the .clang-tidy file,
- Add missing documentation for existing options (User).
- Fix spurious newline after the dash that comes after every
  command-line option. This was inconsistent with single-line
  descriptions, which lacked a newline. The description is now
  aligned with the dash and the corresponding command-line option,
  more visually pleasing.

This enables documenting upcoming global clang-tidy
configuration options.

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

Introduce support for the third kind of values in the transform dialect:
value handles. Similarly to operation handles, value handles are
pointing to a set of values in the payload IR. This enables
transformation to be targeted at specific values, such as individual
results of a multi-result payload operation without indirecting through
the producing op or block arguments that previously could not be easily
addressed. This is expected to support a broad class of memory-oriented
transformations such as selective bufferization, buffer assignment, and
memory transfer management.

Value handles are functionally similar to operation handles and require
similar implementation logic. The most important change concerns the
handle invalidation mechanism where operation and value handles can
affect each other.

This patch includes two cleanups that make it easier to introduce value
handles:

  - `RaggedArray` structure that encapsulates the SmallVector of
    ArrayRef backed by flat SmallVector logic, frequently used in the
    transform interfaces implementation;

  - rewrite the tests that associated payload handles with an integer
    value `reinterpret_cast`ed as a pointer, which were a frequent
    source of confusion and crashes when adding more debugging
    facilities that can inspect the payload.

Reviewed By: springerm

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

LLDB failures: https://lab.llvm.org/buildbot/#/builders/17/builds/33865

This reverts commit 4c228ee6.

The flag is not recognized by clang-cl and emits unused command line warning for every translation unit

According to YAML specification keys must be unique for a mapping node:
"The content of a mapping node is an unordered set of key/value node pairs, with
the restriction that each of the keys is unique".

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

Decoder should make 32 bit value when decoding immediates, not 64 bit.

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

Add test coverage for https://github.com/llvm/llvm-project/issues/60563.
D142636 introduced a bug: incorrect disassembly of floating point inline
constants for v_pk_mov_b32, v_pk_add_f32, v_pk_mul_f32 and v_pk_fma_f32.
Precommit for D143574.

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

Part of https://discourse.llvm.org/t/rfc-switching-the-llvm-dialect-and-dialect-lowerings-to-opaque-pointers/68179

FuncToLLVM contains some logic working with Memrefs and their lowerings and in the process creating pointer types, loads and allocas. This patch ports the code of these to be compatible with opaque pointers and adds a pass option to enable the use of opaque pointers within the pass.

For the migration effort, the tests have been rewritten to use opaque pointers with dedicated test files for typed pointer support

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

In the attached test case we can get into positions where the shift gets a
constant shift amount that is negative or larger than the bitwidth, leading to
trying to create an invalid constant. Add a check to make sure we can handle it
without assertions.

Fixes #60530

When using --name, due to a missing newline, multiple symbol results
were not correctly printed:
```
(lldb) image lookup -r -n "As<.*"
2 matches found in <...>/tbi_lisp:
        Address: tbi_lisp<...>
        Summary: tbi_lisp<...> at Symbol.cpp:75        Address: tbi_lisp<...>
        Summary: tbi_lisp<...> at Symbol.cpp:82
```
It should be:
```
(lldb) image lookup -r -n "As<.*"
2 matches found in /home/david.spickett/tbi_lisp/tbi_lisp:
        Address: tbi_lisp<...>
        Summary: tbi_lisp<...> at Symbol.cpp:75
        Address: tbi_lisp<...>
        Summary: tbi_lisp<...> at Symbol.cpp:82
```
With Address/Summary on separate lines.

Reviewed By: clayborg, labath

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

In the GFX11 VINTERP encoding bits 23, 59 and 60 are unused. Change the
disassembler to ignore these bits.

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

Prevent errors and crash dumps for broken pipes on Windows.

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

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

`getAliasingOpOperands`/`getAliasingOpResults` now encodes OpOperand/OpResult, buffer relation and a degree of certainty. E.g.:
```
// aliasingOpOperands(%r) = {(%t, EQUIV, DEFINITE)}
// aliasingOpResults(%t) = {(%r, EQUIV, DEFINITE)}
%r = tensor.insert %f into %t[%idx] : tensor<?xf32>

// aliasingOpOperands(%r) = {(%t0, EQUIV, MAYBE), (%t1, EQUIV, MAYBE)}
// aliasingOpResults(%t0) = {(%r, EQUIV, MAYBE)}
// aliasingOpResults(%t1) = {(%r, EQUIV, MAYBE)}
%r = arith.select %c, %t0, %t1 : tensor<?xf32>
```

`BufferizableOpInterface::bufferRelation` is removed, as it is now part of `getAliasingOpOperands`/`getAliasingOpResults`.

This change allows for better analysis, in particular wrt. equivalence. This allows additional optimizations and better error checking (which is sometimes overly conservative). Examples:

* EmptyTensorElimination can eliminate `tensor.empty` inside `scf.if` blocks. This requires a modeling of equivalence: It is not a per-OpResult property anymore. Instead, it can be specified for each OpOperand and OpResult. This is important because `tensor.empty` may be eliminated only if all values on the SSA use-def chain to the final consumer (`tensor.insert_slice`) are equivalent.
* The detection of "returning allocs from a block" can be improved. (Addresses a TODO in `assertNoAllocsReturned`.) This allows us to bufferize IR such as "yielding a `tensor.extract_slice` result from an `scf.if` branch", which currently fails to bufferize because the alloc detection is too conservative.
* Better bufferization of loops. Aliases of the iter_arg can be yielded (even if they are not equivalent) without having to realloc and copy the entire buffer on each iteration.

The above-mentioned examples are not yet implemented with this change. This change just improves the BufferizableOpInterface, its implementations and related helper functions, so that better aliasing information is available for each op.

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

This patch updates the remaining SparseCompiler integration tests to
target SVE when available.

Two tests will require some investigation in the future:
  * sparse_matmul.mlir
  * sparse_tanh.mlir
The former passes regardless - that's due to how `CHECK` lines are
defined. The latter fails when SVE is enabled, but passes when it's
disabled. I marked it as UNSUPPORTED as there is no mechanism to XFAIL a
test conditionally. Also, see [1] for more details.

[1] https://github.com/llvm/llvm-project/issues/60626

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

This function was added for ARM targets, but aligning global/stack pointer
arguments passed to memcpy/memmove/memset can improve code size and
performance for all targets that don't have fast unaligned accesses.
This adds a generic implementation that adjusts the alignment to pointer
size if unaligned accesses are slow.
Review D134168 suggests that this significantly improves performance on
synthetic benchmarks such as Dhrystone on RV32 as it avoids memcpy() calls.

Reviewed By: efriedma

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

This part of the test can break if multilib is enabled, and isn't
important to testing the change with which is was added.

The relevant part of the test is
ARM-EABI: "-lclang_rt.builtins-arm"
which remains.

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

YAML specification does not allow keys duplication an a mapping. However, YAML
parser in LLVM does not have any check on that and uses only the last key entry.
In this change duplicated keys are merged to satisfy the spec.

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

The original change mistakenly excluded parameter registers from the
list of callee-saved-registers. This reland fixes it - it only excludes
the return registers for preserve_all/preserve_most CCs.

Original description:
> Currently both calling conventions preserve registers that are used to
> store a return value. This causes the returned value to be lost:
>
>   define i32 @bar() {
>     %1 = call preserve_mostcc i32 @foo()
>     ret i32 %1
>   }
>
>   define preserve_mostcc i32 @foo() {
>     ret i32 2
>     ; preserve_mostcc will restore %rax,
>     ; whatever it was before the call.
>   }
>
> This contradicts the current documentation (preserve_allcc "behaves
> identical to the `C` calling conventions on how arguments and return
> values are passed") and also breaks [[clang::preserve_most]].
>
> This change makes CSRs be preserved iff they are not used to store a
> return value (e.g.  %rax for scalars, {%rax:%rdx} for __int128, %xmm0
> for double).  For void functions no additional registers are
> preserved, i.e.  the behaviour is backward compatible with existing
> code.

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

For simple derived type ConstantEmitter returns a struct of the same
size but different type which is then stored field-by-field into memory
via pointer to derived type. In case base type has more fields than derived,
the incorrect GEP is emitted. So, just cast pointer to derived type to
appropriate type with enough fields.

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

Reviewed By: aaron.ballman

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