CodeExtractor shifts dbg.value intrinsics out of the region being
extracted and updates them to be appropriate in the extracted function.
With new non-intrinsic variable locations, we need to manually do this
too, with DPValues.

Most of this patch shifts and refactors some utilities in
fixupDebugInfoPostExtraction so that we can add a single extra helper
lambda that iterates over DPValues and applies update-utilities. We also
have to assign the IsNewDbgInfoFormat flag in a bunch of places -- this
normally gets set the moment you insert a block into a function (or
function into a module), however a few blocks are constructed here
before being inserted, thus we have to do some manual setup.

Tested via LoopExtractor_alloca.ll, which invokes debugify.

This enables -regalloc=greedy to memfold spillable inline asm
MachineOperands.

Because no instruction selection framework marks MachineOperands as
spillable, no language frontend can observe functional changes from this
patch. That will change once instruction selection frameworks are
updated.

Link: https://github.com/llvm/llvm-project/issues/20571

This got "lost" in the HLFIR transformation. This patch applies the old
attribute to the AssociateOp that needs it, and forwards it to the
AllocaOp that is generated when lowering to FIR.

Currently PresentModifierLocs defined with size DefaultmapKindNum; where
DefaultmapKindNum = OMPC_DEFAULTMAP_pointer + 1

Before 5.0 variable-category can not be omitted. For the test like
\#pragma omp target map(tofrom: errors) defaultmap(present)

error would be mitted.

After 5.0 that is allowd.

When try to:
PresentModifierLocs[DMC->getDefaultmapKind()] =
              DMC->getDefaultmapModifierLoc();
It is accessed beyond array end.

To fix this using OMPC_DEFAULTMAP_unknow instead OMPC_DEFAULTMAP_poiner.

For historic reasons we had it setup that there was
`  plugin-nextgen/common/PluginInterface/<sources + headers>`
which is not what we do anywhere else.
Now it looks like the rest:
```
  plugin-nextgen/common/include/<headers>
  plugin-nextgen/common/src/<sources>
```
As part of this, `dlwrap.h` was moved into common/include (as
`DLWrap.h`)
since it is exclusively used by the plugins.

This should not be needed now that the project uses PRs, plus the
OpenSSF Scorecard report flagged this as insecure.

This flag was added in #67982, but was not yet accessible via the C API.
This commit adds a getter/setter for this flag, and a test for it.

Picolibc is a C Standard Library that is commonly used in embedded
environments. This patch adds initial support for this configuration
along with pre-commit CI. As of this patch, the test suite only builds
the tests and nothing is run. A follow-up patch will make the test suite
actually run the tests.

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

[ELF,LTO] Test calloc defined in a lazy bitcode file for (malloc+memset => calloc) libcall optimization

Similar to https://reviews.llvm.org/D50017: malloc+memset references can
be combined to a calloc reference, which is not explicit in the
referencer's IR symbol table. If calloc is defined in a lazy bitcode
file, we should extract the archive member to satisfy possible
references from LTO generated object files; otherwise (current status,
which will be fixed by #72673), `calloc` as a LazyObject symbol will be
resolved by compileBitcodeFiles generated Undefined, leading to an
incorrectly-extracted Defined symbol without section, which will lower
to an SHN_ABS symbol at address 0.

If a line contains a comment outside of (fake) parentheses, the part
following it is indented according to `CurrentState.Indent`. A Verilog
case label and the statement that follows are broken with
mustBreakBefore. So the part that follows the case label needs some
special handling. Previously, that variable was left out. So the
indentation was wrong when there was a comment.

old:

```Verilog
case (data)
  16'd0:
    result = //
        10'b0111111111;
endcase
case (data)
  16'd0:
    //

  //
  result = //
  10'b0111111111;
endcase
```

new:

```Verilog
case (data)
  16'd0:
    result = //
        10'b0111111111;
endcase
case (data)
  16'd0:
    //

    //
    result = //
        10'b0111111111;
endcase
```

The Verilog implication operator `->` is a binary operator meaning
either the left hand side is false or the right hand side is true.
Previously it was treated as the C++ struct member operator.

I didn't even know it existed when I added the operator formatting part.
And I didn't check all the tests for all the operators I added. That is
how the bad test got in.

Summary:
For reasons unknown to me, this function is undefined only on the GPU
build if you use `uintptr_t` but not `uint64_t` directly. This patch
makes an ifdef to use this directly for the GPU build to fix the bots.

These tests are for fneg canonicalization combines, not codegen coverage tests like most of the other vec_* test files.

Currently AArch64 handles a FrameIndex operand in this function, but we
fail to.

Thing change add builtins for SME2:
    sclamp.single.x2
    uclamp.single.x2
    fclamp.single.x2
    sclamp.single.x4
    uclamp.single.x4
    fclamp.single.x4

Patch by: Hassnaa Hamdi <hassnaa.hamdi@arm.com>

Locale objects use atomic reference counting, which may be very
expensive in parallel applications. The classic locale is used by
default by all streams and can be very contended. But it's never
destroyed, so the reference counting is also completely pointless on the
classic locale. Currently ~70% of time in the parallel stringstream
benchmarks is spent in locale ctor/dtor. And the execution radically
slows down with more threads.

Avoid reference counting on the classic locale. With this change
parallel benchmarks start to scale with threads.

This is a re-application of f8afc53d (aka PR #72112) which was
reverted in 4e0c48b9

 because it broke the sanitizer builds due
to an initialization order fiasco. This issue has now been fixed by
ensuring that the locale is constinit'ed.

Co-authored-by: Dmitry Vyukov <dvyukov@google.com>

We were detecting which sanitizer flags to use when building
libc++.dylib but we were never actually adding those flags to the
targets, which means that our sanitized builds would basically build the
dylib without any sanitizers enabled.

This PR introduce `setmaxregister.sync.aligned` Op to increase or
decrease the register size.


https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#miscellaneous-instructions-setmaxnreg

VSCode's Pylance extension informed me, and text searching confirmed,
that these imports are unused. I believe we should be able to remove
them harmlessly.

This patch refactors tests for:

      vector.contract -> vector.outerproduct

for matvec operations (b += Ax). Summary of changes:
  * names of LIT variables are unified,
  * "plain" tests (i.e. without masking and with fixed-width vectors)
    are moved to the top of their respective sections,
  * missing "plain" cases are added.

This is a part of a larger effort to add cases with scalable vectors to
tests for the Vector dialect. I am refactoring these tests so that it's
easier to identify what cases are tested and where to add tests for
scalable vectors.

Implements #72834.

Split out of getTargetConstantFromBasePtr

Add new implementation of workshare loop functions.

These functions will be used by OpenMPIRBuilder to support
handling of OpenMP workshare loops for the target region.

---------

Co-authored-by: Johannes Doerfert <johannes@jdoerfert.de>

Limit the use to two SDMA engines which are optimized for such transfers.

Debugify is extremely useful as a testing and debugging tool, and a good
number of LLVM-IR transform tests use it. We need it to support "new"
non-instruction debug-info to get test coverage, but it's not important
enough to completely convert right now (and it'd be a large
undertaking). Thus: convert to/from dbg.value/DPValue mode on entry and
exit of the pass, which gives us the functionality without any further
work. The cost is compile-time, but again this is only happening during
tests.

Tested by: the large set of debugify tests enabled here. Note the
InstCombine test (cast-mul-select.ll) that hasn't been fully enabled:
this is because there's a debug-info sinking piece of code there that
hasn't been instrumented.

The internals manual seems like a more obvious home for the details
instead of hiding them away in a header file and relying on doxygen
output to document it publicly.

LOC is a GNU extension, so gfortran is the reference for it, and it
accepts absent OPTIONAL and returns zero. Support this use case in flang
too.

Update the LOC test to use HLFIR while touching it.

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

After merge request #73124, the flang test Driver/ctofortran started
failing because both the C and the Fortran code had main programs. This
update fixes that by eliminating the C main program in the test.

According to the code in `SelectionDAG::getMaskedStore`, the Mask
operator is in position 4, not 3:

     SDValue Ops[] = {Chain, Val, Base, Offset, Mask};

Auto-generate test `armpl-intrinsics.ll` and simplify tests:
- Eliminate scalar tail with no tail-folding flag.
- Use active lane mask for shorter check lines (no long `shufflevectors`).
- Eliminate scalar loops by providing `noalias` to relevant arguments and
run `simplifycfg` to drop them.
- Update script now use `@llvm.compiler.used` instead of a longer regex.

Just leave the (zext (trunc (and x, c))) pattern which is still being used to create some zext_inreg patterns.

Thanks to @yubingex007-a11y for the original test case

It looks like this function is actually unused.