CI checks were passing in #84962 (c48d8182) but
that commit caused failures once merged due to ships passing since the
PR was not rebased on #85131. This commit fixes this problem by adding
sched resources for integer min max instructions from Zbb in P600 model.

This PR includes an initial scheduler model shows improvement on
multiple workloads over NoSchedModel and SiFive7Model for sifive-p670.
We plan on making significant changes to this model in the future so
that it is more accurate. This patch would close
https://github.com/llvm/llvm-project/pull/80612.

Fixes #85628

Just doing this the same way as in AMDGPUPromoteAlloca.cpp

Updated the corelimit.cpp test to handle buildbots with RLIMIT_CORE
rlim_max already set to zero.

Original commit message:

I was trying to debug why `ninja check-compiler-rt` was taking so long
to run on my system and after some debugging it turned out that most of
the time was being spent generating core dumps.

On many current Linux systems, coredumps are no longer dumped in the CWD
but instead piped to a utility such as systemd-coredumpd that stores
them in a deterministic location. This can be done by setting the
kernel.core_pattern sysctl to start with a '|'. However, when using such
a setup the kernel ignores a coredump limit of 0 (since there is no file
being written) and we can end up piping many gigabytes of data to
systemd-coredumpd which causes the test suite to freeze for a long time.
While most piped coredump handlers do respect the crashing processes'
RLIMIT_CORE, this is notable not the case for Debian's systemd-coredump
due to a local patch that changes sysctl.d/50-coredump.conf to ignore
the specified limit and instead use RLIM_INFINITY
(https://salsa.debian.org/systemd-team/systemd/-/commit/64599ffe44f0d).

Fortunately there is a workaround: the kernel recognizes the magic value
of 1 for RLIMIT_CORE to disable coredumps when piping. One byte is also
too small to generate any coredump, so it effectively behaves as if we
had set the value to zero.

The alternative to using RLIMIT_CORE=1 would be to use prctl() with the
PR_SET_DUMPABLE flag, however that also prevents ptrace(), so makes it
impossible to attach a debugger.

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

This reverts commit 0b9f19a9.

Summary:
A recent change made the HIP compilation bundle by default. However we
don't want to do this for `-E`, which silently broke some handling.

This change adds a flag to lld to enable category merging for MachoO +
ObjC.
It adds the '-objc_category_merging' flag for enabling this option and
uses the existing '-no_objc_category_merging' flag for disabling it.
In ld64, this optimization is enabled by default, but in lld, for now,
we require explicitly passing the '-objc_category_merging' flag in order
to enable it.

Behavior: if in the same link unit, multiple categories are extending
the same class, then they get merged into a single category.
Ex: `Cat1(method1+method2,protocol1) + Cat2(method3+method4,protocol2,
property1) = Cat1_2(method1+method2+method3+method4,
protocol1+protocol2, property1)`

Notes on implementation decisions made in this diff:
1. There is a possibility to further improve the current implementation
by directly merging the category data into the base class (if the base
class is present in the link unit) - this improvement may be done as a
follow-up. This improved functionality is already present in ld64.
2. We do the merging on the raw inputSections - after dead-stripping
(categories can't be dead stripped anyway).
3. The changes are mostly self-contained to ObjC.cpp, except for adding
a new flag (linkerOptimizeReason) to ConcatInputSection and StringPiece
to mark that this data has been optimized away. Another way to do it
would have been to just mark the pieces as not 'live' but this would
cause the old symbols to show up in the linker map as being
dead-stripped - even if dead-stripping is disabled. This flag allows us
to match the ld64 behavior.

---------

Co-authored-by: Alex B <alexborcan@meta.com>

This is an alternative to #85610, that moreElement's small G_TRUNC
vectors to widen the vectors. It needs to disable one of the existing
Unmerge(Trunc(..)) combines, and some of the code is not as optimal as
it could be. I believe with some extra optimizations it could look
better (I was thinking combining trunc(buildvector) -> buildvector and
possibly improving buildvector lowering by generating
insert_vector_element earlier).

* Add support for multiple, potentially overlapping critical sections:
  The checker can now simultaneously handle several mutex's critical
  sections without confusing them.
* Implement the handling of recursive mutexes:
  By identifying the lock events, recursive mutexes are now supported.
  A lock event is a pair of a lock expression, and the SVal of the mutex
  that it locks, so even multiple locks of the same mutex (and even by
  the same expression) is now supported.
* Refine the note tags generated by the checker:
  The note tags now correctly show just for mutexes that are
  active at the point of error, and multiple acquisitions of the same mutex
  are also noted.

This reverts commit daebe5c4.

This commit causes the following asan issue:

```
<snip>/llvm-project/build/bin/mlir-opt <snip>/llvm-project/mlir/test/Dialect/XeGPU/XeGPUOps.mlir | <snip>/llvm-project/build/bin/FileCheck <snip>/llvm-project/mlir/test/Dialect/XeGPU/XeGPUOps.mlir
# executed command: <snip>/llvm-project/build/bin/mlir-opt <snip>/llvm-project/mlir/test/Dialect/XeGPU/XeGPUOps.mlir
# .---command stderr------------
# | =================================================================
# | ==2772558==ERROR: AddressSanitizer: stack-use-after-return on address 0x7fd2c2c42b90 at pc 0x55e406d54614 bp 0x7ffc810e4070 sp 0x7ffc810e4068
# | READ of size 8 at 0x7fd2c2c42b90 thread T0
# |     #0 0x55e406d54613 in operator()<long int const*> /usr/include/c++/13/bits/predefined_ops.h:318
# |     #1 0x55e406d54613 in __count_if<long int const*, __gnu_cxx::__ops::_Iter_pred<mlir::verifyListOfOperandsOrIntegers(Operation*, llvm::StringRef, unsigned int, llvm::ArrayRef<long int>, ValueRange)::<lambda(int64_t)> > > /usr/include/c++/13/bits/stl_algobase.h:2125
# |     #2 0x55e406d54613 in count_if<long int const*, mlir::verifyListOfOperandsOrIntegers(Operation*, 
...
```

fixes: #85150

This reverts commit 4109b18e.

It looks like the automatic detection has false positives. This broke
the following build https://github.com/llvm/llvm-project/pull/85262

Slightly improve the readability of the tablegen-generated code.

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

Fixes: #84705
Further fix for #84489

The value of SubExpr is not null since getSubExpr would assert in that
case. Remove the nullptr check. This avoids confusion since SubExpr is
used without check later in the function.

Add two options to control the line break inside TableGen DAGArg.
- TableGenBreakInsideDAGArg
- TableGenBreakingDAGArgOperators

llvm-project/llvm/lib/CodeGen/PrologEpilogInserter.cpp:369:12:
error: unused variable 'MaxCFSIn' [-Werror,-Wunused-variable]
  uint32_t MaxCFSIn =
           ^
1 error generated.

Handle them before shelling out to visitComplexBinOp().

[flang] Diagnose the impure procedure reference in finalization according to the rank of the entity (#85475)

Use the rank of the array section to determine which final procedure
would be called in diagnosing whether that procedure is impure or not.

Cast Offset variable to int64_t type directly inside a multiplication
and function call to utilize 64-bit arithmetic.

Ensure that the multiplication will not overflow.

A static analyzer warned about this since the function expects a 64-bit
argument, but the multiplication is evaluated inside a 32-bit context.

- Use computeMaxCallFrameSize() in PEI::calculateCallFrameInfo() instead of duplicating the code.

- Set AdjustsStack in FinalizeISel instead of in computeMaxCallFrameSize().

Having a mix of tabs and spaces makes the diff of any changes to the
build system noisier than necessary. This commit unifies them to two
spaces.

This includes some minor cosmetic changes such as with joining things on
one line where appropriate.

There are other files in libclc which have tabs but those haven't been
touched at this time. Those could come at another time if desired,
though they might be more contentious as the project isn't
clang-formatted at all and so that might invite larger discussions
around formatting.

The test currenlty fails:
https://lab.llvm.org/buildbot/#/builders/139/builds/61628

because it emits a C11 warning when compiling as C. Try to fix that
be defining the C standard to use.

The LLVM_VERSION_* variables were moved to a new file in
81e20472.

These predicates should be copied from the corresponding Pseudo
instruction. Previously that did not work because of a problem with
setting the right predicates on the Pseudos, but #85442 fixed that.

Generalize pattern matchers to take recipe types to match as template
arguments and use it to provide matchers for unary and binary recipes
with specific opcodes and a list of recipe types (VPWidenRecipe,
VPReplicateRecipe, VPWidenCastRecipe, VPInstruction)

The new matchers are used to simplify and generalize the code in
simplifyRecipes.

Add some Kinds existing in Index.h but missing in cindex.py.

This PR adds the `[us]cmp` intrinsics to the LangRef, `Intrinsics.td`
and some tests to the IRVerifier.

RFC: https://discourse.llvm.org/t/rfc-add-3-way-comparison-intrinsics/76685

A test is added to echo.ll, and the echo.cpp part of llvm-c-test is
updated to clone a function's prefix and prologue.

For the test case in C, both `LV.getLValueOffset()` and
`Ctx.getTypeSizeInChars(Ty)` are zero, so we return `true` from
`isOnePastTheEndOfCompleteObject()` and ultimately diagnose this as
being one past the end, but the diagnostic doesn't make sense.

It's not only the fist CFSTR call that's broken on AIX.
See https://github.com/llvm/llvm-project/commit/0a739eb75fe68b1cec4e4aaad8b5395bb5da9a89#commitcomment-139910542

The clang-tidy selection in CMake was refactored in
https://github.com/llvm/llvm-project/pull/81362. During review it was
suggested to remove this CMake option.

`__unconstrained_reverse_iterator` has outlived its usefullness, since
the standard and subsequently the compilers have been fixed.

Resolves #85065

---------

Co-authored-by: Matt Arsenault <arsenm2@gmail.com>