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

Remove bad test for >2x XLen scalar. Don't restrict struct returns if they aren't homogenous.

Original commit message:
Types larger than 2*XLen are passed indirectly which is not supported
yet. Currently, we will incorrectly pass X10 multiple times.

We currently shrink the type of vmv_s_x_vl to LMUL=1 when its passthru
is
undef to avoid constraining the register allocator since it ignores
LMUL.
This patch relaxes it for non-undef passthrus, which occurs when
lowering
insert_vector_elt.

This reverts commit 3a4b0e93.

Seems to be failing on the build bots.

This handles the case where this combine:
icmp sgt (ashr X, ShAmtC), C --> icmp sgt X, ((C + 1) << ShAmtC) - 1

wasn't performed by instcombine.

Proof of the original combine: https://alive2.llvm.org/ce/z/SfpsvX

This is a port of the review in https://reviews.llvm.org/D151911 to
GitHub.

Types larger than 2*XLen are passed indirectly which is not supported
yet. Currently, we will incorrectly pass X10 multiple times.

This reverts commit c80b5034.

This change causes a fatal error in the backend and is filed as issue #69670.

This commit adjusts the CUDA context management in the SerializeToCubin
pass. In particular, it uses the device 0 primary context instead of
creating a new CUDA context on each invocation of SerializeToCubin. This
yields very large improvements in compile time, especially if an
application (like a JIT compiler) is calling SerializeToCubin
repeatedly.

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



Co-authored-by: Rohan Yadav <rohany@cs.stanford.edu>

Issue: https://github.com/llvm/llvm-project/issues/69270

These atomic primitives are required in order to implement the race
variants of the new And and Or operators in Go's sync/atomic package.
See Github issue golang/go#61395.

This caused linker issues on a buildbot:
https://lab.llvm.org/buildbot/#/builders/61/builds/50716.

This reverts commit 3c07a216.

MSVC has a major performance regression observed when targeting ARM64
since v19.32 (VS 17.2.0). `cl.exe` spends a lot of time on compiling
`StandardLibrary.cpp` and `CGBuiltin.cpp`, and total build duration
rises extremely. This makes builds stagnate even on a real hardware, but
VM-based builds (like building on cloud agents from GitHub Actions and
Azure Pipelines) are experiencing most damage as they also performance-
and time-limited.

The issue appears to be related to some optimizations applied in `/O2`
mode. It is reported on [Developer
Community](https://developercommunity.visualstudio.com/t/Compiling-a-specific-code-for-ARM64-with/10444970).
While the investigation is in progress, we could apply a workaround to
improve build time. `/O2` actually enables a set of optimizations, and
only one of them does all slowdown. The idea is to disable
optimizations, and then apply all but one back, effectively excluding
the problematic option from the set.

This patch alters the CMake configuration for aforementioned files.
Changes are limited to:
- non-debug builds
- MSVC of the specific version
- target arch (ARM64).