Merge branch 'users/skatrak/spr/wsloop-wrapper-01-mlir' into users/skatrak/spr/wsloop-wrapper-02-dependent-ops

Merge branch 'users/skatrak/spr/wsloop-wrapper-01-mlir' into users/skatrak/spr/wsloop-wrapper-02-dependent-ops

I have a tutorial at EuroLLVM 2024 ([Zero to Hero: Programming Nvidia
Hopper Tensor Core with MLIR's NVGPU
Dialect](https://llvm.swoogo.com/2024eurollvm/session/2086997/zero-to-hero-programming-nvidia-hopper-tensor-core-with-mlir's-nvgpu-dialect)).
For that, I implemented tutorial codes in Python. The focus is the nvgpu
dialect and how to use its advanced features. I thought it might be
useful to upstream this.

The tutorial codes are as follows:
- **Ch0.py:** Hello World
- **Ch1.py:** 2D Saxpy
- **Ch2.py:** 2D Saxpy using TMA
- **Ch3.py:** GEMM 128x128x64 using Tensor Core and TMA 
- **Ch4.py:** Multistage performant GEMM using Tensor Core and TMA
- **Ch5.py:** Warp Specialized GEMM using Tensor Core and TMA

I might implement one more chapter:

- **Ch6.py:** Warp Specialized Persistent ping-pong GEMM

This PR also introduces the nvdsl class, making IR building in the
tutorial easier.

[TTI] getArithmeticInstrCost - use std:nullopt to create default empty `ArrayRef<const Value *> Args` argument. NFC.

Noticed in #89897

Missed from #88378, only showed up in the sanitizer builds.

See RFC at
https://discourse.llvm.org/t/rfc-add-an-interface-for-top-level-container-operations

I previously did the same for the AbstractResult pass
https://github.com/llvm/llvm-project/pull/88867

It turned out that `hlfir::genVariableBox` didn't add lower bounds to
the boxes it created. Using a shapeshift instead of only a shape adds
the lower bounds information to the thread-local copy of the box.

Fixes #89259

[SPIR-V] Fix pre-legalizer pass in SPIR-V Backend to support more gMIR opcode inserted by IRTranslator (#89890)

Translating global values, IRTranslator pass can sometimes generates
code patterns that require additional efforts during pre-legalization.
This PR addresses this problem to support G_PTRTOINT instruction used in
initialization of GV.

This PR fixes the issue
https://github.com/llvm/llvm-project/issues/88908
Attached test case is updated to check that OpSConvert/OpUConvert is not
generated when input and result types are identical.

Refactor to be closer to foldShuffleOfCastops - sibling patch to #88743 that can be used to address some of the issues identified in #88693

We've recently seen the libclc llvm-link invocations become so long that
they exceed the character limits on certain platforms.

Using a 'response file' should solve this by offloading the list of
inputs into a separate file, and using special syntax to pass it to
llvm-link. Note that neither the response file nor syntax aren't
specific to Windows but we restrict it to that platform regardless. We
have the option of expanding it to other platforms in the future.

Fixes the bot failure at
https://lab.llvm.org/buildbot/#/builders/272/builds/14788.

Coding my way home: 6.48551S, 128.21109W

[InstCombine] Simplify `(X / C0) * C1 + (X % C0) * C2` to `(X / C0) * (C1 - C2 * C0) + X * C2` (#76285)

Since `DivRemPairPass` runs after `ReassociatePass` in the optimization
pipeline, I decided to do this simplification in `InstCombine`.

Alive2: https://alive2.llvm.org/ce/z/Jgsiqf
Fixes #76128.

This patch adds test coverage for commutable RVV instructions
added in #88379.

For each kind of instruction, I add two tests (one for unmasked and
one for masked). These tests don't cover all the SEWs/LMULs as I
think it's not worthy because there is no difference when handling
instructions with different SEWs/LMULs.

As the tests shown, we can't eliminate two equal instructions if
there is a use of `V0`. This may be fixed in the future.

Reviewers: asb, jacquesguan, topperc, lukel97, preames

Reviewed By: lukel97

Pull Request: https://github.com/llvm/llvm-project/pull/89889

This is missing e.g. on Windows. With this change, it's possible to make
the libcxx std module work on mingw-w64 (although that requires a few
fixes to those headers).

In the regular cstdlib header, we have _LIBCPP_USING_IF_EXISTS flagged
on every single reexported function (since
a9c9183c), but the modules seem to only
have _LIBCPP_USING_IF_EXISTS set on a few individual functions, so far.

With GFX12 architected SGPRs the workgroup ids are trivially available
in any function called from a compute entrypoint.

The previous state was leading to inconsistencies. Some targets would
get the options and some wouldn't. As an example, the `MEMORY_COPTS`
definitions would only apply to the `:string_memory_utils` target but
not to the `:memcpy` target. This patch makes sure definitions are
applied throughout the LLVM libc targets as `local_defines`. This
ensures that the preprocessor definitions don't propagate to depending
targets outside of LLVM libc, and that all libc targets have consistent
preprocessor definitions.

This patch splits off part of the work to move vsetvli insertion to post
regalloc in #70549.

The doLocalPostpass operates outside of RISCVInsertVSETVLI's dataflow,
so we can move it to its own pass. We can then move it to post vector
regalloc which should be a smaller change.

A couple of things that are different from #70549:

- This manually fixes up the LiveIntervals rather than recomputing it
via createAndComputeVirtRegInterval. I'm not sure if there's much of a
difference with either.
- For the postpass it's sufficient enough to just check isUndef() in
hasUndefinedMergeOp, i.e. we don't need to lookup the def in VNInfo.

Running on llvm-test-suite and SPEC CPU 2017 there aren't any changes in
the number of vsetvlis removed. There are some minor scheduling diffs as
well as extra spills and less spills in some cases (caused by transient
vsetvlis existing between RISCVInsertVSETVLI and RISCVCoalesceVSETVLI
when vec regalloc happens), but they are minor and should go away once
we finish moving the rest of RISCVInsertVSETVLI.

We could also potentially turn off this pass for unoptimised builds.

This patch adds new tests mostly checking SPIR-V validation of pointer
and primitive types.

This document has never been on the website, unlike GDB's protocol docs.
It will be useful to have both available online to compare.

Markdown is easier to edit and preview in many editors (including Github
itself), so I've chosen that over RST. Plus, building the website takes
minutes and I lose the will to make nice edits when I have to deal with
that.

The standard dialiect lacks some things notably multi-line table cells,
so I've converted large tables into bullet point lists
so that we still get text wrapping. This is a downside but I think the
simplicity of Markdown outweighs this.

I have applied the plain text markers where I've noticed it and escaped
some HTML characters. There may be more changes needed but, it's
Markdown, so it's in theory a lot easier for someone to fix it!

Fixes the failure at https://lab.llvm.org/buildbot/#/builders/131/builds/62928,
and add comments about unused variable and update debugging output.

Coding my way home: 6.44615S, 128.16704W

Introduce a mechanism to share data between the ARM and AArch64 backends and
TargetParser, to reduce duplication of code. This is similar to the current
RISC-V implementation.

The target tablegen file (in this case `ARM.td` or `AArch64.td`) is
processed during building of `TargetParser` to generate the following
files in the build tree:
 - `build/include/llvm/TargetParser/ARMTargetParserDef.inc`
 - `build/include/llvm/TargetParser/AArch64TargetParserDef.inc`

For now, the use of these generated files is limited to files _outside_
of `TargetParser`. The main reason for this is that the modifications to
`TargetParser` will require additional data added to the tablegen files,
which I want to split into separate PRs.

A follow-up to #71709, addressing the static analysis finding reported in https://github.com/llvm/llvm-project/pull/71709/files#r1576846306

RST is powerful but usually too powerful for 90% of what we need it for.
Markdown is easier to edit and can be previewed easily without building
the entire website.

This copies what llvm does already, making myst_parser optional if you
only want man pages.

Previously we had Markdown enabled in
8b95bd33 but that got reverted. That did
this in a different way but I've gone with the standard llvm set this
time.

I intend the first Markdown pages to be the remote protocol extension
docs, as they are not in any set format right now.

With `nsw`/`nuw`, the `trunc` is non-zero if its operand is non-zero.

Proofs: https://alive2.llvm.org/ce/z/iujmk6

Closes #89643

llvm-project/llvm/lib/ExecutionEngine/Orc/LLJIT.cpp:684:8:
error: unused variable 'ConcurrentCompilationSettingDefaulted' [-Werror,-Wunused-variable]
  bool ConcurrentCompilationSettingDefaulted = !SupportConcurrentCompilation;
       ^
1 error generated.

The vast majority of the following (very common) opcodes were always
called with identical arguments:

- `GIM_CheckType` for the root
- `GIM_CheckRegBankForClass` for the root
- `GIR_Copy` between the old and new root
- `GIR_ConstrainSelectedInstOperands` on the new root
- `GIR_BuildMI` to create the new root

I added overloaded version of each opcode specialized for the root
instructions. It always saves between 1 and 2 bytes per instance
depending on the number of arguments specialized into the opcode. Some
of these opcodes had between 5 and 15k occurences in the AArch64
GlobalISel Match Table.

Additionally, the following opcodes are almost always used in the same
sequence:

- `GIR_EraseFromParent 0` + `GIR_Done` 
- `GIR_EraseRootFromParent_Done` has been created to do both. Saves 2
bytes per occurence.
- `GIR_IsSafeToFold` was *always* called for each InsnID except 0.
- Changed the opcode to take the number of instructions to check after
`MI[0]`

The savings from these are pretty neat. For `AArch64GenGlobalISel.inc`:
- `AArch64InstructionSelector.cpp.o` goes down from 772kb to 704kb (-10%
code size)
- Self-reported MatchTable size goes from 420380 bytes to 352426 bytes
(~ -17%)

A smaller match table means a faster match table because we spend less
time iterating and decoding.
I don't have a solid measurement methodology for GlobalISel performance
so I don't have precise numbers but I saw a few % of improvements in a
simple testcase.

This re-applies 6094b3b7, which was reverted in e7efd37c (and before that
in 1effa19d) due to bot failures.

The test failures were fixed by having SelfExecutorProcessControl use an
InPlaceTaskDispatcher by default, rather than a DynamicThreadPoolTaskDispatcher.
This shouldn't be necessary (and indicates a concurrency issue elsewhere), but
InPlaceTaskDispatcher is a less surprising default, and better matches the
existing behavior (compilation on current thread by default), so the change
seems reasonable. I've filed https://github.com/llvm/llvm-project/issues/89870
to investigate the concurrency issue as a follow-up.

Coding my way home: 6.25133S 127.94177W

Split vector and scalar regalloc has been enabled by default for 5
months now since d0a39e61, and shipped
with 18.1.0. I haven't heard of any issues with it so far, so this
proposes to remove the flag to reduce the number of configurations we
have to support.