A cmake patch append compile options `-Wno-unused-but-set-parameter` is
merged.

This reverts commit 82ae83a8.

If we update the state, or indicate a pessimistic fixpoint, we need to
consider NestedParallelism too.

Fixes part of https://github.com/llvm/llvm-project/issues/66708

That said, the reproducer still needs malloc which we don't support on
AMD GPU. Will be added later.

The underlying timezone classes are being reimplemented in Swift, and these 
strings will be Swift strings, without the ObjC `@` prefix. Leaving off the `@` 
makes these tests usable both before and after the reimplmentation of 
Foundation in Swift.

This patches changes the docs action to run a fetch with a depth of the
number of commits in the PR (1 if we're just running against a push
event) which significantly increases the speed of the changed files
event. The changed files event goes from taking ~30m to ~3s without any
noticeable increase in fetch time.

`getStorageLocation` may return `nullptr` and this will produce crash
when use `cast`, use `dyn_cast_or_null` instead. I test it locally using
[FTXUI](https://github.com/ArthurSonzogni/FTXUI) and it may be the cause
of issue [issue](https://github.com/llvm/llvm-project/issues/68412), but
I am not sure.

Co-authored-by: huqizhi <huqizhi@836744285@qq.com>

Fixes https://github.com/llvm/llvm-project/issues/69730 (also see
https://reviews.llvm.org/D155543).

There are  two things outstanding (why I didn't land before):

1. add some C API tests for `mlirOperationWalk`;
2. potentially refactor how the invalidation in `run` works; the first
version of the code looked like this:
    ```cpp
    if (invalidateOps) {
      auto *context = op.getOperation().getContext().get();
      MlirOperationWalkCallback invalidatingCallback =
          [](MlirOperation op, void *userData) {
            PyMlirContext *context =
                static_cast<PyMlirContext *>(userData);
            context->setOperationInvalid(op);
          };
      auto numRegions =
          mlirOperationGetNumRegions(op.getOperation().get());
      for (int i = 0; i < numRegions; ++i) {
        MlirRegion region =
            mlirOperationGetRegion(op.getOperation().get(), i);
        for (MlirBlock block = mlirRegionGetFirstBlock(region);
             !mlirBlockIsNull(block);
             block = mlirBlockGetNextInRegion(block))
          for (MlirOperation childOp =
                   mlirBlockGetFirstOperation(block);
               !mlirOperationIsNull(childOp);
               childOp = mlirOperationGetNextInBlock(childOp))
            mlirOperationWalk(childOp, invalidatingCallback, context,
                              MlirWalkPostOrder);
      }
    }
    ```
This is verbose and ugly but it has the important benefit of not
executing `mlirOperationEqual(rootOp->get(), op)` for every op
underneath the root op.

Supposing there's no desire for the slightly more efficient but highly
convoluted approach, I can land this "posthaste".
But, since we have eyes on this now, any suggestions or approaches (or
needs/concerns) are welcome.

Try to transform the powi(X, Y) / X into powi(X, Y-1) with Ofast.
For this case, when the Y is 3, then powi(X, 2) is replaced by X * X in
the further step.

Fixes https://github.com/llvm/llvm-project/pull/67216
Reviewed By: dtcxzyw, nikic, jcranmer-intel

Relates to #69736

Signed-off-by: Diogo Teles Sant'Anna <diogoteles@google.com>

[RISCV][GISel] Minor refactoring of RISCVCallReturnHandler and RISCVIncomingValueHandler to match other targets (#69757)

Forward assignValueToReg to the base class to make the copy. Add
markPhysRegUsed to contain the differences between call handling and
argument handling. Introduce RISCVFormalArgHandler.

This structure matches how AArch64, AMDGPU, and X86 are structured.

I've also added `MIRBuilder.getMRI()->addLiveIn(PhysReg);` to match the
other targets.

In SimplifyIndvar::replaceFloatIVWithIntegerIV() the return value of
getFPMantissaWidth() was being cast as an unsigned integer and then
compared with the number of bits needed to represent an integer that was
cast to and from a floating-point type. This is a problem because
getFPMantissaWidth() returns -1 if the type does not have a stable
mantissa.

Currently the only type that returns -1 is ppc_fp128, so you'd need a
pretty big induction variable to cause a problem. However, this problem
will be more likely to be exposed when we implement support for decimal
floating-point types.

Strictly speaking, what we want to know here is the size of the biggest
integer that can be represented exactly. We could get that information
even with an unstable mantissa width, but getFPMantissaWidth() won't do
it.

This patch enables scalable vectors in the VPlan-native path.
If a vectorization factor is specified via loop vectorization hints,
that factor is used. If no vectorization factor is specified, but the
target preferes scalable vectorization, a scalable vectorization factor
is selected.

Reviewed By: fhahn

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

Fix type errors that mypy reports with code-format-helper.py.

Add a few return type annotations and change `param: [str]` to
`param: list[str]`.

Leave a few required FormatHelper members missing instead of defining a
placeholder:
 - FormatHelper.name
 - FormatHelper.friendly_name
 - FormatHelper.format_run: NotImplementedError() instead of `pass`

This patch adds translation for `if` clause on `teams` construct in
OpenMP Dialect.

…tVRegSExtVal

The implementation of these methods uses
getIConstantVRegValWithLookThrough with LookThroughInstrs argument set
to false. By adding the optional argument to getIConstantVRegVal and
getIConstantVRegSExtVal we can take advantage of the already built look
through functionality.

…L based on instruction EEW

Vector Unit Stride Loads and stores EEW and EMUL depend on the EEW given
in the instruction name and the SEW from vtype. llvm-mca needs some help to correctly report
this information.

MSVC in C mode apparently doesn't consider `const int` to be
sufficiently constant expression

This was broken in #66903.

- For a better understand of what the unsupported cases are, we add
  more information to the debug note---a string of ancestor AST nodes
  of the unclaimed DRE. For example, an unclaimed DRE p in an
  expression `*(p++)` will result in a string starting with
  `DRE ==> UnaryOperator(++) ==> Paren ==> UnaryOperator(*)`.

- To find out the most common patterns of those unsupported use cases,
  we add a simple script to build a prefix tree over those strings and
  count each prefix. The script reads input line by line, assumes a
  line is a list of words separated by `==>`s, and builds a prefix tree
  over those lists.

Reviewed by: t-rasmud (Rashmi Mudduluru), NoQ (Artem Dergachev)

Differential revision: https://reviews.llvm.org/D158561

Currently, `linalg.transpose` and `linalg.broadcast` can't be emitted
through either the C API or the python bindings (which of course go
through the C API). See
https://discourse.llvm.org/t/how-to-build-linalg-transposeop-in-mlir-pybind/73989/10.

The reason is even though they're named ops, there is no opdsl
`@linalg_structured_op` for them and thus while they can be instantiated
they cannot be passed to
[`mlirLinalgFillBuiltinNamedOpRegion`](https://github.com/llvm/llvm-project/blob/a7cccb9cbb2b9954684cbea37615303a59719973/mlir/lib/CAPI/Dialect/Linalg.cpp#L18).
I believe the issue is they both take a `IndexAttrDef` but
`IndexAttrDef` cannot represent dynamic rank. Note, if I'm mistaken and
there is a way to write the `@linalg_structured_op` let me know.

The solution here simply implements the `regionBuilder` interface which
is then picked up by
[`LinalgDialect::addNamedOpBuilders`](https://github.com/llvm/llvm-project/blob/7...

The MinGW mode (enabled with the flag -lldmingw) does allow duplicate
weak symbols. A test in
compiler-rt/test/profile/Windows/coverage-weak-lld.cpp does currently
enable the -lldmingw flag in an MSVC context, in order to deal with
duplicate weak symbols.

Add a new, separate, lld specific flag for enabling this. In MinGW mode,
this is enabled by default, otherwise it is disabled.

This allows making the MinGW mode more restrictive in adding libpaths
from the surrounding environment; in MinGW mode, all libpaths are passed
explicitly by the compiler driver to the linker, which is attempted in
https://reviews.llvm.org/D144084.

This adds actual test cases for all the cases that are listed in a code
comment in the implementation of this function; having such test
coverage eases doing further modifications to the function.

This relands b4b35a5d. This time,
the new test is excluded if building with dylibs or shared libraries
enabled, as the clang::toolchains::Generic_GCC class is marked
LLVM_LIBRARY_VISIBILITY, giving it hidden visibility in such builds,
making it unreferencable outside of the dylib/shared library.

When an include from a textual header is resolved, the textual header's
submodule is used as the requesting module. The submodule's uses are
resolved, but that doesn't work because only top level modules have
uses, and only the top level module uses are used for checking uses in
Module::directlyUses. ModuleMap::resolveUses to resolve the top level
module instead of the submodule.

Summary:
We should not rely on a VLA in C++ for the handling of this string. The
size is a true runtime value so we cannot rely on constexpr handling. We
simply use a small vector, whose default size is most likely large
enough to handle whatever size gets output within the stack, but is safe
in cases where it is not.

The entry point symbol handling matches our GCC link spec..
```%{!shared:%{!nostdlib:%{!r:%{!e*:-e __start}}}}```

Remove usage of -Bdynamic as it is the default for the linker anyway.

Came up in discussion here https://github.com/llvm/llvm-project/pull/65644

So we can differentiate on the while keyword between a do-while-loop and
a normal while-loop.

- only return when the return type is non-void
- fix missing return on member functions

Correcting a small typo in the error message when the CUDA device libraries are not detected.

The implicit conversion from an op to a Value is not triggered for some reasons:

/LoopLikeSCFOpsTest.cpp:78:57: error: call of overloaded ‘ValueRange(mlir::arith::ConstantIndexOp)’ is ambiguous
       b.create<scf::ParallelOp>(loc, ValueRange(lb.get()), ValueRange(ub.get()),

explicitly taking the result of the op should solve it.

The llvm.exp.* family of intrinsics and their corresponding libcalls
were recently added, which means we need to know their signatures.

This just reorganizes the code to make it clear what the existing cases were
doing in common.  An upcoming change will extend the logic.

Legalizer, register bank selection, and instruction selection.