This reverts commit dc61ebb4.

See https://github.com/llvm/llvm-project/pull/76733#issuecomment-1890311152.

Incorporates the changes from
https://github.com/llvm/llvm-project/pull/80786 to use a once_flag from
`TestUtilities` instead of a local flag in order to prevent hitting an
assertion that the debugger was initialized again in another test.

Enable the environment variable inside the test environment. This allows
to disable SDMA engine transfers as a potential mitigation of flaky
OpenMP offloading tests on AMDGPU.

Motivated by the open ticket https://github.com/ROCm/ROCm/issues/2616
about a missed synchronization signal.

gathers, NFC.

I tried adding a new unit test to the core test
suite (https://github.com/llvm/llvm-project/pull/79533) but it broke the
test suite on AArch64 Linux due to hitting an assertion for calling
`Debugger::Initialize` more than once. When the unit test suite is
invoked as a standalone binary the test suite state is shared, and
`Debugger::Initialize` gets called in `DiagnosticEventTest.cpp` before
being called in `ProgressReportTest.cpp`.

`DiagnosticEventTest.cpp` uses a call_once flag to initialize the
debugger but it's local to that test. This commit adds a once_flag to
`TestUtilities` so that `Debugger::Initialize` can be called once by the
tests that use it.

There was an error where dividend of type i64 and actual used number of
bits of 32 fell into path that assumes only 24 bits being used. Check
that AtLeast field is used correctly when using computeNumSignBits and
add necessary extend/trunc for 32 bits path.

Regolden and update testcases.

@jrbyrnes @bcahoon @arsenm @rampitec

Fixes a typo in llvm/lib/MC/MCObjectStreamer.cpp introduced in #80162

[ARM][AARCH64][NEON]: Wrong return type of NEON intrinsic  vqrshrunh_n_s16, vqrshruns_n_s32, and vqrshrund_n_s64 in arm_neon.h (#80819)

* fixes https://github.com/llvm/llvm-project/issues/71751
* changed return types in the table gen file responsible for generation
  of the problematic intrinsics
* this is to ensure that the return type for the functions is the same
  as specified in the Arm Developer Documentation and avoid casting
bugs

(https://developer.arm.com/architectures/instruction-sets/intrinsics/vqrshrunh_n_s16)
* updated lit tests to reflect the change in return type, worth noting
  that LLVM does not seems to differentiate signed and unsigned ints in
the IR, hence the change in type cannot be checked in IR as far as I am
aware

PAL Metadata 3.0 introduces an explicit structure in metadata for the
programmable registers written out by the compiler backend.
The previous approach used opaque registers which can change between different
architectures and required encoding the bitfield information in the backend,
which may change between versions.

This change is an extension the previously added support - which only handled
entry functions. This adds support for all functions.

The change also includes some re-factoring to separate common code.

C_FILE symbols. To match the behavior of the assembler and the legacy
compiler, this includes using the generic ".file" name for the C_FILE
symbol and generating the actual file name in an auxiliary entry.

Inspired by InstCombinerImpl::foldAndOrOfICmpsUsingRanges with some
adaptations to MIR.

Standard file:
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/

Notice that we are not quite the same as other implementations:
1. MUSL: https://github.com/bminor/musl/blob/master/include/inttypes.h
2. GLIBC:
https://github.com/bminor/glibc/blob/bbd248ac0d75efdef8fe61ea69b1fb25fb95b6e7/stdlib/inttypes.h#L57
3. CheriBSD:
https://github.com/CTSRD-CHERI/cheribsd/blob/698d1636dd1fe2322e5bc7029e415928c80b76b1/sys/arm64/include/_inttypes.h

fixes #80186

In https://github.com/llvm/llvm-project/pull/76873 a warning was added
when the macros INFINITY and NAN are used in binary expressions when
-menable-no-nans or -menable-no-infs are used. If the user uses an
option that nullifies these two options, the warning will still be
generated. This patch adds an additional information to the warning
comment to let the user know about this. It also suppresses the warning
when #ifdef INFINITY, #ifdef NAN, #ifdef NAN or #ifndef NAN are used in
the code.

Get more precise cost of instruction after LoopUnroll considering that
some operands of it can be simplified, e.g. induction variable will be
replaced by constant after full unrolling.

Generalize the logic used to convert column-vector ops to row-vectors to
support converting chains of operations.

A potential next step is to further generalize this to convert
column-vector ops to row-vector ops in general, not just for operands of
dot products. Dot-product handling would then be driven by the general
conversion, rather than the other way around.

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

Summary:
Oops.

Assume no side-effects in the presence of a cashed result in the form
of an APValue. This is also what the current interpreter does.

These are aliases for instructions which are are only available when the
fp-armv8 or neon features are enabled, so their predicates should be set
appropriately.

This is an optimisation patch that shouldn't have any functional effect.
There's no need for all instructions to have a DPMarker attached to them,
because not all instructions have adjacent DPValues (aka dbg.values).

This patch inserts the appropriate conditionals into functions like
BasicBlock::spliceDebugInfo to ensure we don't step on a null pointer when
there isn't a DPMarker allocated. Mostly, this is a case of calling
createMarker occasionally, which will create a marker on an instruction
if there isn't one there already.

Also folded into this is the use of adoptDbgValues, which is a natural
extension: if we have a sequence of instructions and debug records:

    %foo = add i32 %0,...
    # dbg_value { %foo, ...
    # dbg_value { %bar, ...
    %baz = add i32 %...
    %qux = add i32 %...

and delete, for example, the %baz instruction, then the dbg_value records
would naturally be transferred onto the %qux instruction (they ...

Summary:
Some recent changes allowed us to remove target level divergence one
these instructions. This patch removes the wavefront dependent
divergence for the ballot and thread ID functions, as well as the clock.
The changes to the "Vendor" library simply disables target specific
optimizations in the implementation. This should be removed in its
entirety when the LLVM `libm` is sufficiently implemented.

The remaining areas of divergence is only the RPC packet size and the
fixed frequency counter.

Correct llvm-reduce strictfp test to follow the rules documented in the
LangRef:
https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics

This test needed the strictfp attribute added to a function call.

Note that attributes of intrinsics cannot be changed in declarations,
but attributes can be changed in call sites. Thus the changes to the
declarations. And the constrained intrinsics have strictfp attributes
by default.

Test changes verified with D146845.

In some cases, when privatizing a threadprivate common block, the
original symbol will correspond to the common block, instead of
its threadprivate version. This can happen, for instance, with a
common block, declared in a separate module, used by a parent
procedure and privatized in its child procedure. In this case,
symbol lookup won't find a symbol in the parent procedure, but
only in the module where the common block was defined.

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

This is patch 1 of 4, to add support for COPYPRIVATE.
Original PR: https://github.com/llvm/llvm-project/pull/73128

C23 has `bool`, but logical operators still return int. Check that
we're not in C to avoid false-positive -Wconstant-logical-operand.

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

getExportName implementation is based on lld-link. In its current form,
it's mostly about convenience, but it will be more useful for EXPORTAS
support, for which export name is not possible to deduce from other
printed properties.

If we have a `SETCC (SETCC), 0, NE` and ZeroOrOneBooleanContent, we can remove
the outer setcc as it will produce the same value as the inner. This can be
generalized to anything where the top bits are known to be 0, as the value will
remain as 1 or 0.

This PR outlines the arguments of the open CodeGen functions into 2
separate structs. This was, in part, motivated by the delayed
privatization WIP #79862 where we had to extend the signatures of both
functions containing quite a bit of default values (`nullptr`, `false`).
This PR does not add any new arguments yet though, just outlines the
existing ones.

[DAG] visitCTPOP - if only the upper half of the ctpop operand is zero then see if its profitable to only count the lower half. (#80473)

Change the semantics of Pointer::isDummy() to check for a null
Pointee and returnd false in that case. Then call CheckDummy()
in ArrayElemPtr{,Pop} to protect those ops from operating on
dummy pointers and enable a few tests in test/Sema/ that now
work with the new constant interpreter.

The enums needed by the file MachineValueType.h are auto-generated since commit
ddaf085e

We can convert concat(v4i16 uhadd(a,b), v4i16 uhadd(c,d)) to v8i16
uhadd(concat(a,c), concat(b,d)), which can lead to further
simplifications.

Follow up to #79476 - that patch added a call to hoistLockstepIdenticalDPValues
which hoists identical DPValues in lockstep, matching dbg intrinsic hoisting
behaviour. The code deleted in this patch, which unconditionally hoists
DPValues, should have been deleted in that patch.

Update test with --try-experimental-debuginfo-iterators to check the behaviour.

Follow up to #79476 - that change introduces a call to
hoistLockstepIdenticalDPValues.

The TargetGuard fields for 'svldr[_vnum]_za' and 'svstr[_vnum]_za' were
incorrectly set to `+sve` instead of `+sme`. This means that compiling
code that uses these intrinsics requires compiling for both `+sve` as
well as `+sme`.

This PR also fixes the target guards for the `svadd` and `svsub`
builtins that are enabled under `+sme2,+sme-i16i64` and
`+sme2,+sme-f64f64`, as it initially did the following:
```
  let TargetGuard = "+sme2" in {
    let TargetGuard = "+sme-i16i64" in {
      // Builtins defined here will be predicated only by
      // '+sme-i16i64', and not '+sme2,+sme-i16i64'.
    }
  }
```
This PR also removes `-target-feature +sve` from all the SME tests, to
ensure that the SME features are sufficient to build the tests.