Prefer the new flag -lld-allow-duplicate-weak (which was added recently
in a67ae8c0), over the old -lldmingw.

The -lldmingw option enables a number of different behaviours, while
this test only is interested in one aspect of them.

This should allow making -lldmingw more strict with not enabling MSVC
specific behaviours like inferring lib directories automatically from
the environment, as being pursued in https://reviews.llvm.org/D144084.

When the user specifies `LIBCXX_HARDENING_MODE` on the command line in a
bootstrapping build, it should override the setting implied by
`LLVM_ENABLE_ASSERTIONS`.

This patch fixes:

  compiler-rt/lib/builtins/int_to_fp_impl.inc:22:18: error: expression
  is not an integer constant expression; folding it to a constant is a
  GNU extension [-Werror,-Wgnu-folding-constant]

by using enum for constants.

There were a couple of typos of "If" -> "In" in Debug.h

Not too much to change here. Just found some issues with the flang
GettingStarted.md file and wanted to sort it out.

When this file is included in a project compiled with GCC 13 `-Werror`,
compilation fails with the following diagnostic:
<pre>
/usr/lib/llvm-17.0/include/clang/AST/TypeLoc.h: In constructor
'clang::TypeSourceInfo::TypeSourceInfo(clang::QualType, size_t)':
/usr/lib/llvm-17.0/include/clang/AST/TypeLoc.h:245:9: error: 'void*
memset(void*, int, size_t)' clearing an object of non-trivial type
'class clang::TypeSourceInfo'; use assignment instead
[-Werror=class-memaccess]
  245 |   memset(this + 1, 0, DataSize);
      |   ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~

</pre>
To avoid this, we add an explicit type cast. The cast to `void*` makes
sense, since other member functions of `TypeSourceInfo` also treat the
buffer `(this + 1)` of length `DataSize` as opaque memory, and was
likely left out by mistake.

Fixes: 4498663f ("[AST] Initialized data after TypeSourceInfo")

I also suggest to apply this to release/17.x if possible.

Print the name of the module/function/loop the pass
ran on.

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/7557530f428a2f226d8d925c33d527dfcfdcb0c5/mlir/lib/Dialect/Linalg/IR/LinalgDialect.cpp#L116).

Extension classes are added "by hand" that mirror the API of the
`@linalg_structured_op`s. Note, the extension classes are added to to
`dialects/linalg/__init__.py` instead of
`dialects/linalg/opdsl/ops/core_named_ops.py` in order that they're not
confused for opdsl generators/emitters.

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.