If we have interleave groups in the loop we want to vectorise then
we should fall back on normal vectorisation with a scalar epilogue. In
such cases when tail-folding is enabled we'll almost certainly go on to
create vplans with very high costs for all vector VFs and fall back on
VF=1 anyway. This is likely to be worse than if we'd just used an
unpredicated vector loop in the first place.

Once the vectoriser has proper support for analysing all the costs
for each combination of VF and vectorisation style, then we should
be able to remove this.

Added an extra test here:

  Transforms/LoopVectorize/AArch64/sve-tail-folding-option.ll

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

[RISCV][NFCI] Set TransientStackAlignment and rely on it rather than RVV-specific logic on RVV-less functions

* TargetFrameLowering has a TransientStackAlignment field that "returns
  the number of bytes to which the stack pointer must be aligned at all
  times, even between calls.
  * As explained in the [RISC-V calling
    convention](https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc),
    the stack pointer must remain fully aligned throughout execution for
    compliant code. This is important for embedded targets that might avoid
    realigning the stack pointer for interrupt service routines. Systems
    running full OSes may always realign the stack anyway.
* TransientStackAlignment is used in estimateStackSize in
  MachineFrameInfo and in PEI::calculateFrameObjectOffsets.
  * estimateStackSize is only used in the RISC-V backend for scavenging
    slots. It may be possible to craft a function where the difference
    is observable, but it wouldn't be a meaningful test.
  * calculateFrameObjectOffsets makes use of TransientStackAlignment,
    but then sets the stack alignment to the max of that alignment and
    MaxAlign, which is unconditionally set to 16 in
    RISCVFrameLowering::processFunctionBeforeFrameFinalized
  * I've changed this logic to only set MaxAlign if there are RVV frame
    objects. There should be no functional change here for either RVV
    targets (MaxAlign is set as before) or non-RVV targets
    (TransientStackAlign is now 16 anyway).

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

The CPU is used to determine which inline asm instructions are allowed, so
needs to be copied across in case the outlined function contains any.

Reviewed By: asb

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

This fixes warnings like these:

../runtime/src/kmp_dispatch.cpp:2159:24: warning: left operand of comma operator has no effect [-Wunused-value]
    OMPT_LOOP_DISPATCH(*p_lb, *p_ub, pr->u.p.st, status);
                       ^~~~~
../runtime/src/kmp_dispatch.cpp:2159:31: warning: left operand of comma operator has no effect [-Wunused-value]
    OMPT_LOOP_DISPATCH(*p_lb, *p_ub, pr->u.p.st, status);
                              ^~~~~
../runtime/src/kmp_dispatch.cpp:2159:46: warning: left operand of comma operator has no effect [-Wunused-value]
    OMPT_LOOP_DISPATCH(*p_lb, *p_ub, pr->u.p.st, status);
                                     ~~~~~~~ ^~
../runtime/src/kmp_dispatch.cpp:2159:50: warning: expression result unused [-Wunused-value]
    OMPT_LOOP_DISPATCH(*p_lb, *p_ub, pr->u.p.st, status);
                                                 ^~~~~~

Now the API getExtendedAddReductionCost is used to determine the cost of extended Add reduction with optional Mul. For Arm, it could cover the cases. But for other target, for example: RISCV, they support other kinds of extended recution, such as FAdd.

This patch does the following changes:
1, Split getExtendedAddReductionCost into 2 new API: getExtendedReductionCost which handles the extended reduction with addtional input of Opcode; getMulAccReductionCost which handle the MLA cases the getExtendedAddReductionCost.
2, Refactor getReductionPatternCost, add some contraint condition to make sure the getMulAccReductionCost should only handle the reuction of Add + Mul.

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

When the mlir-tblgen tool is set up, the `MLIR_TABLEGEN_EXE` variable
is set, which either points to the mlir-tblgen tool built in the current
cmake build, or points to one built in a nested cmake build (if cross
conpiling, or if building with e.g. `LLVM_OPTIMIZED_TABLEGEN`.

The `MLIR_TABLEGEN_EXE` variable is only set within the scope of the
mlir/CMakeLists.txt file, so it's unavailable in sibling level projects
such as flang.

Set the `MLIR_TABLEGEN_EXE` and the `MLIR_TABLEGEN_TARGET` variables
as global, so that flang can use them properly without guessing.

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

If CMAKE_CROSSCOMPILING, then the newly built flang-new executable was
cross compiled and thus can't be executed on the build system, and thus
can't be used for generating module files.

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

CMAKE_DL_LIBS is documented as "Name of library containing dlopen
and dlclose".

On Windows platforms, there's no system provided dlopen/dlclose, but
it can be argued that if you really intend to call dlopen/dlclose,
you're going to be using a third party compat library like
https://github.com/dlfcn-win32/dlfcn-win32, and CMAKE_DL_LIBS should
expand to its name.

This has been argued upstream in CMake in
https://gitlab.kitware.com/cmake/cmake/-/issues/17600 and
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/1642, that
CMAKE_DL_LIBS should expand to "dl" on mingw platforms.

The merge request wasn't merged though, as it caused some amount of
breakage, but in practice, Fedora still carries a custom CMake patch
with the same effect.

Thus, this patch fixes cross compiling OpenMP for mingw targets
on Fedora with their custom-patched CMake.

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

Supporting something like `-fxray-instruction-threshold= 1` is not intended.

Introduced in D130356, reported here:
https://reviews.llvm.org/rG7ac7ec820296#inline-7690

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

Added support for incremental mode 8 and 28 ie. `frontend::EmitBC:` and `frontend::PrintPreprocessedInput:`
Added supporting clang tests to test in clang-repl mode

Reviewed By: v.g.vassilev

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

Similar to -o and -Map.

According to [RISC-V ISA Spec](https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf) and [riscv-v-spec](https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#3-vector-extension-programmers-model)

Reviewed By: DavidSpickett

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

Previously when we add module initializer, we forget to handle header
units. This results that we couldn't compile a Hello World Example with
Header Units. This patch tries to fix this.

Reviewed By: iains

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

This patch adds constant folder for TanOp which only supports single and double precision floating-point.

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

This reverts commit db6152ad.

This commit fails in ppc64. Since we want to backport it to 15.x. So
revert it now to keep the patch complete.

Also update -ftime-trace='s help to fix a recommonmark error.

Previously when we add module initializer, we forget to handle header
units. This results that we couldn't compile a Hello World Example with
Header Units. This patch tries to fix this.

Reviewed By: iains

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

Previously, DenseArrayAttr used VectorType for its shaped type.
VectorType is problematic for arrays because it doesn't support zero
dimensions, meaning that an empty array would have `vector<i32>` as its
type. ElementsAttr would think that an empty dense array is size 1, not
0. This patch switches over to TensorType, which does support zero
dimensions.

Fixes #56860

Reviewed By: mehdi_amini

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

Reviewed By: michaelrj, lntue

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

Reviewed By: davidxl

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

Fixes compilation error.

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

Adds optional attribute to support tensor cores on F32 datatype by lowering to `mma.sync` with TF32 operands. Since, TF32 is not a native datatype in LLVM we are adding `tf32Enabled` as an attribute to allow the IR to be aware of `MmaSyncOp` datatype. Additionally, this patch adds placeholders for nvgpu-to-nvgpu transformation targeting higher precision tf32x3.

For mma.sync on f32 input using tensor cores there are two possibilites:
(a) tf32   (1 `mma.sync` per warp-level matrix-multiply-accumulate)
(b) tf32x3 (3 `mma.sync` per warp-level matrix-multiply-accumulate)

Typically, tf32 tensor core acceleration comes at a cost of accuracy from missing precision bits. While f32 has 23 precision bits, tf32 has only 10 precision bits. tf32x3 aims to recover the precision bits by splitting each operand into two tf32 values and issue three `mma.sync` tensor core operations.

Reviewed By: ThomasRaoux

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

Reflect in the pointer's offset the length of the leading part
of the consumed string preceding the first converted digit.

Reviewed By: efriedma

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

As progress towards having FileEntryRef contain the requested name of
the file, this commit narrows the "remap" hack to only apply to paths
that were remapped to an external contents path by a VFS. That was
always the original intent of this code, and the fact it was making
relative paths absolute was an unintended side effect.

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