The element type is declared as SmallVector<T, 1>, but we assign to
SmallVector<T> &. These types are not the same on 32-bit systems,
resulting in a compilation error.

Fix this by using SmallVectorImpl<T> & instead, which is independent
of the small size.

For inline asm with memory operands, we can merge the offset into
the second operand of memory constraint operands.

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

SIMemoryLegalizer tests were slow, with most of them taking 4.5 to 5.3s
to complete and that's on a fast machine. I also recall seeing them in
the slowest tests list on build bots.

This removes the verify-machineinstrs option from these tests to speed
them up, bringing the slowest test down to +-2s.
Verifier still runs in EXPENSIVE_CHECKS builds.

This adds a new `mlir_arm_runner_utils` library that contains utils
specific to Arm/AArch64. This is for use in MLIR integration tests.

This initial patch adds `setArmVLBits()` and `setArmSVLBits()`. This
allows changing vector length or streaming vector length at runtime (or
setting it to a known minimum, i.e. 128-bits).

Existing 'arith::ConstantOp' conversion and tests are moved from
VectorToArmSME. There's currently only a single op that's converted at
the moment, but this will grow in the future as things like in-tile add
are implemented. Also, 'createLoopOverTileSlices' is moved to ArmSME
utils since it's relevant for both conversions.

This means we don't have to chmod, or change permissions any other way.

Follow-up to #69422.

This PR puts all the highlighting settings into a single struct for
easier handling

Co-authored-by: Talha Tahir <talha.tahir@10xengineers.ai>

When emitting notes related to wrong number of arguments do not consider
object argument.

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

This reverts commit 745883bb.

This is failing to configure on many of our bots:
https://lab.llvm.org/buildbot/#/builders/245/builds/19468

This did not get caught right away because generally bots only
clean the build every so often.

[MLIR][Presburger] Implement function to evaluate the number of terms in a generating function. (#78078)

We implement `computeNumTerms()`, which counts the number of terms in a
generating function by substituting the unit vector in it.
This is the main function in Barvinok's algorithm – the number of points
in a polytope is given by the number of terms in the generating function
corresponding to it.
We also modify the GeneratingFunction class to have `const` getters and
improve the simplification of QuasiPolynomials.

Multiple places rely on implicit conversion when assigning 'size_t'
values to the member fields (size or capacity) of SmallVector.

Depending on the platform / compiler configuration, this may result in
narrowing conversion warnings (especially given that the size type of
SmallVector's member fields is determined based on type T - in
SmallVector<T>). To avoid the problem altogether, make the conversions
explicit.

Co-authored-by: Orest Chura <orest.chura@intel.com>

These will be supported in the upcoming 2.2 release and so are gated on
that version.

Direct methods call `objc_send_initialize` if they are class methods
that may not have called initialize. This is guarded by checking for the
class flag bit that is set on initialisation in the class. This bit now
forms part of the ABI, but it's been stable for 30+ years so that's fine
as a contract going forwards.

Fixes #44186

---------

Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>

Revert "[Clang][Sema] Diagnose function/variable templates that shadow their own template parameters (#78274)"

This reverts commit fc025326.

This errors is disruptive to downstream projects
and should be reintroduced as a separate on-by-default
warning.

https://github.com/llvm/llvm-project/pull/78274

When we generate the loop body function, we need to be sure, that all
original loop counters are replaced by the new counter.

We need to save all items which use the original loop counter and then
perform replacement of the original loop counter. If we don't do it,
there is a risk that some values are not updated.

/Users/jiefu/llvm-project/llvm/lib/CodeGen/MachinePipeliner.cpp:1044:19: error: moving a temporary object prevents copy elision [-Werror,-Wpessimizing-move]
 1044 |     CycleInstrs = std::move(Schedule.reorderInstructions(SSD, CycleInstrs));
      |                   ^
/Users/jiefu/llvm-project/llvm/lib/CodeGen/MachinePipeliner.cpp:1044:19: note: remove std::move call here
 1044 |     CycleInstrs = std::move(Schedule.reorderInstructions(SSD, CycleInstrs));
      |                   ^~~~~~~~~~                                              ~
/Users/jiefu/llvm-project/llvm/lib/CodeGen/MachinePipeliner.cpp:1395:21: error: moving a temporary object prevents copy elision [-Werror,-Wpessimizing-move]
 1395 |     auto LastUses = std::move(computeLastUses(OrderedInsts, Stages));
      |                     ^
/Users/jiefu/llvm-project/llvm/lib/CodeGen/MachinePipeliner.cpp:1395:21: note: remove std::move call here
 1395 |     auto LastUses = std::move(computeLastUses(OrderedInsts, Stages));
      |                     ^~~~~~~~~~                                     ~
/Users/jiefu/llvm-project/llvm/lib/CodeGen/MachinePipeliner.cpp:1502:9: error: moving a temporary object prevents copy elision [-Werror,-Wpessimizing-move]
 1502 |         std::move(computeMaxSetPressure(OrderedInsts, Stages, MaxStage + 1));
      |         ^
/Users/jiefu/llvm-project/llvm/lib/CodeGen/MachinePipeliner.cpp:1502:9: note: remove std::move call here
 1502 |         std::move(computeMaxSetPressure(OrderedInsts, Stages, MaxStage + 1));
      |         ^~~~~~~~~~                                                         ~
/Users/jiefu/llvm-project/llvm/lib/CodeGen/MachinePipeliner.cpp:3381:19: error: moving a temporary object prevents copy elision [-Werror,-Wpessimizing-move]
 3381 |     cycleInstrs = std::move(reorderInstructions(SSD, cycleInstrs));
      |                   ^
/Users/jiefu/llvm-project/llvm/lib/CodeGen/MachinePipeliner.cpp:3381:19: note: remove std::move call here
 3381 |     cycleInstrs = std::move(reorderInstructions(SSD, cycleInstrs));
      |                   ^~~~~~~~~~                                     ~
4 errors generated.

In software pipelining, when searching for the Initiation Interval (II),
`MachinePipeliner` tries to reduce register pressure, but doesn't check
how many variables can actually be alive at the same time. As a result,
a lot of register spills/fills can be generated after register
allocation, which might cause performance degradation. To prevent such
cases, this patch adds a check phase that calculates the maximum
register pressure of the scheduled loop and reject it if the pressure is
too high. This can be enabled this by specifying
`pipeliner-register-pressure`. Additionally, an II search range is
currently fixed at 10, which is too small to find a schedule when the
above algorithm is applied. Therefore this patch also adds a new option
`pipeliner-ii-search-range` to specify the length of the range to
search. There is one more new option
`pipeliner-register-pressure-margin`, which can be used to estimate a
register pressure limit less than actual for conservative analysis.

Discourse thread:
https://discourse.llvm.org/t/considering-register-pressure-when-deciding-initiation-interval-in-machinepipeliner/74725

Put I and Zi* together. Put F/D/Zf* together. Put A and Za* together,
etc.

This patch updates the cp.async.bulk.{commit/wait}_group Ops to use NVVM
intrinsics.
* Doc updated for the commit_group Op.
* Tests are added to verify the lowering to the intrinsics.

While we are there, fix the FileCheck directive on the
'nvvm.setmaxregister' test.

Signed-off-by: Durgadoss R <durgadossr@nvidia.com>

The current implementation of `nvvm.wgmma.mma_async` Op deduces the data
type of the output matrix from the data type of struct member, which can be
non-intuitive, especially in cases where types like `2xf16` are packed
into `i32`.

This PR addresses this issue by improving the Op to include an explicit
data type for the output matrix.

The modified Op now includes an explicit data type for Matrix-D (<f16>),
and looks as follows:

```
%result = llvm.mlir.undef : !llvm.struct<(struct<(i32, i32, ...
nvvm.wgmma.mma_async
    %descA, %descB, %result,
    #nvvm.shape<m = 64, n = 32, k = 16>,
    D [<f16>, #nvvm.wgmma_scale_out<zero>],
    A [<f16>, #nvvm.wgmma_scale_in<neg>, <col>],
    B [<f16>, #nvvm.wgmma_scale_in<neg>, <col>]
```

This PR fixes the 'nvgpu.warpgroup.mma.store' index calculation. When
the destionation memref and current accumulator matrix were small, the
previous code was reaching out of range.

Changed Things:
- Mentioning we need to specify BMIs for indirectly dependent BMIs too.
- Remove the note for `delayed-template-parsing` since
  https://github.com/llvm/llvm-project/issues/61068 got closed.
- Add a note for https://github.com/llvm/llvm-project/issues/78850 since
  we've seen it for a lot of times.
- Add a note for https://github.com/llvm/llvm-project/issues/78173 since
  we've seen it for a lot of times.

Split up and refactor CLANG_BOLT_INSTRUMENT into support for
BOLT instrumentation, perf no-LBR and perf with LBR profiling.

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

This is clearly a copy-paste mistake, fix it with this patch.
After checking the `local.function_name` is not null, it should check
the len for `local.function_name`, not `local.name`. And this could lead
to possible null dereference since the second
`internal_strlen(local.name)` does not guarantee `local.name` is not
null.

The tests are testing that specifying individual Zvk* extensions
set the preprocessor directives for Zvk* shorthand extensions.

None of the shorthands refer to Zvbb so we should use Zvkb(which
is implied by Zvbb).

Implements: https://wg21.link/P0543R3
- https://eel.is/c++draft/numeric.sat

Additional references:
- Division: https://eel.is/c++draft/expr.mul#4
- Arithmetic conversions: https://eel.is/c++draft/expr.arith.conv#1
- Clang builtins:
https://clang.llvm.org/docs/LanguageExtensions.html#builtin-functions

Depends on: https://github.com/llvm/llvm-project/pull/78086



---------

Co-authored-by: Zingam <zingam@outlook.com>
Co-authored-by: Mark de Wever <zar-rpg@xs4all.nl>

The enc/dec of promoted AMX-TILE instructions have been supported in
https://github.com/llvm/llvm-project/pull/76210.
This patch support lowering for promoted AMX-TILE instructions and
integrate test to existing tests.

https://github.com/llvm/llvm-project/pull/76125 supported the enc/dec
for CMPCCXADD instructions, this patch
1. Add lowering test for promoted CMPCCXADD
2. Update the representation of condition code for promoted CMPCCXADD to
align with the existing one