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
    A...

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

Reland D143267: [LoopVectorize] Use DataLayout::getIndexType instead of i32 for non-constant GEP indices.

Fixed issue where 'ConstantInt::get(IndextTy, -Part)' was executed with the wrong type for Part,
e.g. IndexTy was i64, but Part was 'unsigned', which led to things like 'mul i64 .., 4294967292',
which was obviously wrong.

Also changed sve-vector-reverse.ll to be vectorized with UF>1 to test this.

This reverts commit 1f01cdda.

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

The revision adds a number of extra arguments to the
atomic read modify write and compare and exchange
operations. The extra arguments include the volatile,
weak, syncscope, and alignment attributes.

The implementation also adapts the fence operation to use
a assembly format and generalizes the helper used
to obtain the syncscope name.

Reviewed By: Dinistro

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

Fix https://github.com/llvm/llvm-project/issues/60209

Fix crash with segmentation fault when transform::WithPDLPatternsOp is
applied with non-pattern op. Added check for existing transform ops with
pattern op.

Reviewed By: ftynse

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

This commit removes the `llvm.struct_attr` which was used to bundle
result attributes that were previously attached to multiple results.
This extension isn't part of LLVM as result attribute semantics cannot
be supported on a struct field granularity.
Furthermore, many usages promoted result attributes to argument
attributes but this does not necessary preserve the semantics.

Reviewed By: gysit

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

This is to avoid unnecessary traversals of the IR.

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