This patch makes changes to the `scf.parallel` to `omp.parallel` + `omp.wsloop`
lowering pass in order to introduce a nested `omp.loop_nest` as well, and to
follow the new loop wrapper role for `omp.wsloop`.

This PR on its own will not pass premerge tests. All patches in the stack are
needed before it can be compiled and passes tests.

This patch updates verifiers for `omp.ordered.region`, `omp.cancel` and
`omp.cancellation_point`, which check for a parent `omp.wsloop`.

After transitioning to a loop wrapper-based approach, the expected direct
parent will become `omp.loop_nest` instead, so verifiers need to take this into
account.

This PR on its own will not pass premerge tests. All patches in the stack are
needed before it can be compiled and passes tests.

This patch updates the definition of `omp.wsloop` to enforce the restrictions
of a loop wrapper operation.

Related tests are updated but this PR on its own will not pass premerge tests.
All patches in the stack are needed before it can be compiled and passes tests.

This commit explicitly specifies the matching mode (C library function,
any non-method function, or C++ method) for the `CallDescription`s
constructed in the iterator/container checkers.

This change won't cause major functional changes, but isn't NFC because
it ensures that e.g. call descriptions for a non-method function won't
accidentally match a method that has the same name.

Separate commits will perform (or have already performed) this change in
other checkers. My goal is to ensure that the call description mode is
always explicitly specified and eliminate (or strongly restrict) the
vague "may be either a method or a simple function" mode that's the
current default.

I'm handling the iterator checkers in this separate commit because
they're infamously complex; but I don't expect any trouble because this
transition doesn't interact with the "central" logic of iterator
handling.

This patch simplifies the lowering from PFT to MLIR of OpenMP compound
constructs (i.e. combined and composite).

The new approach consists of iteratively processing the outermost leaf
construct of the given combined construct until it cannot be split
further. Both leaf constructs and composite ones have `gen...()`
functions that are called when appropriate.

This approach enables treating a leaf construct the same way regardless
of if it appeared as part of a combined construct, and it also enables
the lowering of composite constructs as a single unit.

Previous corner cases are now handled in a more straightforward way and
comments pointing to the relevant spec section are added. Directive sets
are also completed with missing LOOP related constructs.

Fixes #85084

Whenever an inferior thread stops, lldb-server sends a SIGSTOP to all
other threads in the process to force them to stop as well. If those
threads stop on their own before they get a signal, this SIGSTOP will
remain pending and be delivered the next time the process resumes.

Normally, this is not a problem, because lldb-server will detect this
stale SIGSTOP and resume the process. However, if we detach from the
process while it has these SIGSTOPs pending, they will get immediately
delivered, and the process will remain stopped (most likely forever).

This patch fixes that by sending a SIGCONT just before detaching from
the process. This signal cancels out any pending SIGSTOPs, and ensures
it is able to run after we detach. It does have one somewhat unfortunate
side-effect that in that the process's SIGCONT handler (if it has one)
will get executed spuriously (from the process's POV).

This could be _sometimes_ avoided by tracking which threads got send a
SIGSTOP, and whether those threads stopped due to it. From what I could
tell by observing its behavior, this is what gdb does. I have not tried
to replicate that behavior here because it adds a nontrivial amount of
complexity and the result is still uncertain -- we still need to send a
SIGCONT (and execute the handler) when any thread stops for some other
reason (and leaves our SIGSTOP hanging). Furthermore, since SIGSTOPs
don't stack, it's also possible that our SIGSTOP/SIGCONT combination
will cancel a genuine SIGSTOP being sent to the debugger application (by
someone else), and there is nothing we can do about that. For this
reason I think it's simplest and most predictible to just always send a
SIGCONT when detaching, but if it turns out this is breaking something,
we can consider implementing something more elaborate.

One alternative I did try is to use PTRACE_INTERRUPT to suspend the
threads instead of a SIGSTOP. PTRACE_INTERUPT requires using
PTRACE_SEIZE to attach to the process, which also made this solution
somewhat complicated, but the main problem with that approach is that
PTRACE_INTERRUPT is not considered to be a signal-delivery-stop, which
means it's not possible to resume it while injecting another signal to
the inferior (which some of our tests expect to be able to do). This
limitation could be worked around by forcing the thread into a signal
delivery stop whenever we need to do this, but this additional
complication is what made me think this approach is also not worthwhile.

This patch should fix (at least some of) the problems with
TestConcurrentVFork, but I've also added a dedicated test for checking
that a process keeps running after we detach. Although the problem I'm
fixing here is linux-specific, the core functinoality of not stopping
after a detach should function the same way everywhere.

"Till heaven and earth pass, one jot, or one tittle shall not pass of
the law"

As we've added new IR elements for the RemoveDIs project,
we need the update_test_checks script to understand them. For the
records themselves this is already done automatically, but their
metadata arguments are not recognized as such due to lacking the
`metadata` prefix, which means they won't be checked by the script. This
patch fixes this by adding a check for all `![0-9]+` patterns as long as
they are not at the start of a line (which avoids matching global
values).

In vxrm.mir we were running RISCVInsertVSETVLI on pseudos that already had
vsetvlis inserted and their AVLs set to $noreg. (This happened to work
since doLocalPostpass got rid of the extra vsetvli)

This removes the vsetvlis from the test and enforces that the only valid
AVLs we work with are either X0 or virtual registers (or $noreg before
emitVSETVLIs), since we don't handle physical registers properly in
doLocalPostpass.

This patch removes the LoopControl parsing/printing functions that are
no longer used after transitioning `omp.simdloop` and `omp.taskloop`
into loop wrapper operations.

This patch updates the definition of `omp.simdloop` to enforce the
restrictions of a wrapper operation. It has been renamed to `omp.simd`,
to better reflect the naming used in the spec. All uses of "simdloop" in
function names have been updated accordingly.

Some changes to Flang lowering and OpenMP to LLVM IR translation are
introduced to prevent the introduction of compilation/test failures. The
eventual long term solution might be different.

Collect the original check lines in a manner that is independent of
where the check lines appear in the file. This is so that we keep
FileCheck variable names stable even when --include-generated-funcs is
used.

Reported-by: Ruiling Song <ruiling.song@amd.com>

This patch introduces a new VPWidenMemoryRecipe base class and distinct
sub-classes to model loads and stores.

This is a first step in an effort to simplify and modularize code
generation for widened loads and stores and enable adding further more
specialized memory recipes.

PR: https://github.com/llvm/llvm-project/pull/87411

When a local variable inside a BLOCK construct is used as threadprivate
variable, llvm-flang throws below error:

> error: The THREADPRIVATE directive and the common block or variable in
it must appear in the same declaration section of a scoping unit

This PR addresses an issue that may arise when an integer argument size
differs from a machine word size for the target in a call to llvm
intrinsic. The following example demonstrates the issue:

```
@__const.test.arr = private unnamed_addr addrspace(2) constant [3 x i32] [i32 1, i32 2, i32 3]

define spir_func void @test() {
entry:
  %arr = alloca [3 x i32], align 4
  %dest = bitcast ptr %arr to ptr
  call void @llvm.memcpy.p0.p2.i32(ptr align 4 %dest, ptr addrspace(2) align 4 @__const.test.arr, i32 1024, i1 false)
  ret void
}

declare void @llvm.memcpy.p0.p2.i32(ptr nocapture writeonly, ptr addrspace(2) nocapture readonly, i32, i1)
```

Depending on the target this code may work or may fail without this PR
due to the fact that IR Translation step introduces additional `zext`
when type of the 3rd argument of `@llvm.memcpy.p0.p2.i32` differs from
machine word.

This PR addresses the issue by adding type deduction for a newly
inserted G_ZEXT generic opcode.

[SPIR-V] Improve Tablegen instruction selection and account for a pointer size of the target (#88725)

This PR resolves the issue that SPIR-V Backend uses the notion of a
pointer size of the target, most notably, in legalizer code, but
Tablegen instruction selection in SPIR-V Backend doesn't account for a
pointer size of the target. See
https://github.com/llvm/llvm-project/issues/88723 for a detailed
description. There are 3 test cases attached to the PR that reproduced
the issue, when dealing with spirv32-spirv64 differences, and are
working correctly now with this PR.

Currently, it is not possible to find back which fun.func is the host
procedure of some internal procedure because the mangling of the
internal procedure does not contain info about the BIND(C) name of the
host.
This info may be useful to ensure dwarf DW_TAG_subprogram of internal
procedures are nested under DW_TAG_subprogram of host procedures for
instance.

Change all the cstval_pred_ty based PatternMatch helpers (things like
m_AllOnes and m_Zero) to only allow poison elements inside vector
splats, not undef elements.

Historically, we used to represent non-demanded elements in vectors
using undef. Nowadays, we use poison instead. As such, I believe that
support for undef in vector splats is no longer useful.

At the same time, while poison splat elements are pretty much always
safe to ignore, this is not generally the case for undef elements. We
have existing miscompiles in our tests due to this (see the
masked-merge-*.ll tests changed here) and it's easy to miss such cases
in the future, now that we write tests using poison instead of undef
elements.

I think overall, keeping support for undef elements no longer makes
sense, and we should drop it. Once this is done consistently, I think we
may also consider allowing poison in m_APInt by default, as doing that
change is much less risky than doing the same with undef.

This change involves a substantial amount of test changes. For most
tests, I've just replaced undef with poison, as I don't think there is
value in retaining both. For some tests (where the distinction between
undef and poison is important), I've duplicated tests.

I was debugging space separation issues when passing user arguments
and noticed this error is really hard to read in that scenario.

Put "" around the invalid compiler name so you can tell whether
you have spaces around it that's causing the problem.

For lowering bitreverse using GFNI, the check is put under SSSE3. This can be pulled out of SSSE3.

Co-authored-by: shami <shami_thoke@yahoo.com>

[libc][msan] Fix "non-constexpr function '__msan_unpoison' cannot be used in a constant expression" (#88719)

Prior to this patch, calling `cpp::bit_cast<T>` in `constexpr`
expressions under `-fsanitize=memory` would fail with the following
message "non-constexpr function '__msan_unpoison' cannot be used in a
constant expression".

This patch makes sure that the `__msan_unpoison` expression is guarded
by `!__builtin_is_constant_evaluated()`.

This commit fixes the following error when stopping the sparse compiler
pipeline after bufferization (e.g., with `test-analysis-only`):

```
LLVM ERROR: Building op `vector.print` but it isn't known in this MLIRContext: the dialect may not be loaded or this operation hasn't been added by the dialect. See also https://mlir.llvm.org/getting_started/Faq/#registered-loaded-dependent-whats-up-with-dialects-management
```

Reverts llvm/llvm-project#88928

This broke the AMDGPU buildbots:
https://lab.llvm.org/buildbot/#/builders/193/builds/50201 
https://lab.llvm.org/staging/#/builders/185/builds/5565
https://lab.llvm.org/buildbot/#/builders/259/builds/2955

Convert it to scoped enum, and move it to namespace scope to enable forward declarations.

We were running this immediately on the incoming IR, which
is still littered with temporary allocas obscuring trivial values.
This needs to run after initial SROA to handle sincos insertion.

This reverts commit c309dc6d.

Breaks builds, see discussion in https://github.com/llvm/llvm-project/pull/83124

This reverts commit 5c6af605.

Breaks builds, see discussion in https://github.com/llvm/llvm-project/pull/83124

This reverts commit 0a789ea8.

Breaks builds, see discussion in https://github.com/llvm/llvm-project/pull/83124

This patch adds the support for Zama16b version 1.0, which has been
added to RVA23U64 optional extensions recently

If LLVM is configured with -DLLVM_DEFAULT_TARGET_TRIPLE, or compiler_rt
is configured with -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE, while the
argument is not normalized, such as Debian-style vendor-less triple,
clang will try to find libclang_rt in lib/<normalized_triple>, while
libclang_rt is placed into lib/<triple_arg>.

Let's also place libclang_rt into lib/<normalized_triple>.

This makes it forward-declarable, and needed from splitting `Sema` up.

This patch includes a test that assert-fails without the fix.

This commit adds `walk` method to PyOperationBase that uses a python
object as a callback, e.g. `op.walk(callback)`. Currently callback must
return a walk result explicitly.

We(SiFive) have implemented walk method with python in our internal
python tool for a while. However the overhead of python is expensive and
it didn't scale well for large MLIR files. Just replacing walk with this
version reduced the entire execution time of the tool by 30~40% and
there are a few configs that the tool takes several hours to finish so
this commit significantly improves tool performance.

This patch adds a test that assert-fails without the fix.

Relates to #88181

Fixes #88181

Per [tab:time.format.spec]
%z  The offset from UTC as specified in ISO 8601-1:2019, subclause
    5.3.4.1. For example -0430 refers to 4 hours 30 minutes behind UTC.
    If the offset is zero, +0000 is used. The modified commands %Ez and
    %Oz insert a : between the hours and minutes: -04:30. If the offset
    information is not available, an exception of type format_error is
    thrown.

Typically the modified versions Oz or Ez would have wording like

  The modified command %OS produces the locale's alternative
  representation.

In this case the modified version does not depend on the locale.

This change is a preparation for formatting sys_info which has time zone
information. The function time_put<_CharT>::put() does not have proper
time zone support, therefore it's a manual implementation.

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

Instead of searching all encodings, we can convert the encoding back to
a register and use getMatchingSuperReg.