This patch canonicalizes the fcmp range check idiom into `fabs + fcmp`
since the canonicalized form is better than the original form for the
backends.
Godbolt: https://godbolt.org/z/x3eqPb1fz
```
and (fcmp olt/ole/ult/ule x, C), (fcmp ogt/oge/ugt/uge x, -C) --> fabs(x) olt/ole/ult/ule C
or  (fcmp ogt/oge/ugt/uge x, C), (fcmp olt/ole/ult/ule x, -C) --> fabs(x) ogt/oge/ugt/uge C
```
Alive2: https://alive2.llvm.org/ce/z/MRtoYq

With e8512786 the for loop that iterates
over MDNode operands was changed to a range-based for loop. This change
surfaces a bug where if the result of MD->operands() is an ArrayRef that
has a size of 0, then iterating over that ArrayRef leads to a
segmentation fault, due to accessing invalid addresses.
    
This was reverted with 6ce03ff3 but this
test should be added to test that codepath in the future.

We had "+zca" instead of "zca". The previous line used "c", not "+c".

This may not be a functional change. I think the function we pass this
to strips any '+' or '-'.

Add clang-tidy check to suggest replacement of conditional statement with std::min/std::max (#77816)

This pull request fixes #64914 where author suggests adding a
readability check to propose the replacement of conditional statements
with std::min/std::max for improved code readability. Additionally,
reference is made to PyLint's similar checks:
[consider-using-min-builtin](https://pylint.pycqa.org/en/latest/user_guide/messages/refactor/consider-using-min-builtin.html)
and
[consider-using-max-builtin](https://pylint.pycqa.org/en/latest/user_guide/messages/refactor/consider-using-max-builtin.html)

In github PR #78731 it looks like I added test coverage for RemoveDIs to
either the wrong test, or not enough. Adding
--try-experimental-debuginfo-iterators to this particular test is enough to
restore some coverage it seems.

This adds missing features to the tests and removes a stale feature
(unimplemented_simd128) from them.

The pread function wasn't properly unpoisoning its result under msan,
causing test failures downstream when I tried to roll it out. This patch
adds the msan unpoison call that fixes the issue.

Testing the shift-exponent check with small width _BitInt values exposed
a bug in ScalarExprEmitter::GetWidthMinusOneValue when using the result
to determine valid exponent sizes. False positives were reported for
some left shifts when width(LHS)-1 > range(RHS) and false negatives were
reported for right shifts when value(RHS) > range(LHS). This patch caps
the maximum value of GetWidthMinusOneValue to fit within range(RHS) to
fix the issue with left shifts and fixes a code generation in EmitShr to
fix the issue with right shifts and renames the function to
GetMaximumShiftAmount to better reflect the new behaviour.

Fixes #80135.

Co-authored-by: Adam Magier <adam.magier@ericsson.com>

The size for the long double BLOCK_BUFFER_LEN is calculated based on the
properties of the long double type. Somewhere in the calculation, the
result was mis-rounded so that the buffer was one element too small.
This patch fixes the issue and adds asserts to catch it sooner in the
future.

This patch does the following folds if only the overflow result is used:
```
extractvalue (umul.with.overflow iN X, X), 1 -> icmp ugt X, 2^(N/2)-1
```
Alive2: https://alive2.llvm.org/ce/z/a8yPC6

This file was previously approved and merged from this PR:
https://github.com/llvm/llvm-project/pull/79533 but caused a test
failure on the Linux AArch64 bots due to hitting an assertion that
`Debugger::Initialize` was already called.

To fix this, this commit uses the
changes made here: https://github.com/llvm/llvm-project/pull/80786 to
use a shared call_once flag to initialize the debugger.

The Errno type doesn't need to be explicitly namespaced now that it's
enclosed in a namespace.

Using a single underscore creates a reference target. If the target
name has the same name as another link, we get a "Duplicate target name"
warning. This is currently happening for Ssqosid.

Using __ prevents this. I've converted all links so no one trips over
this in the future.

One link was missing any underscores so wasn't a link at all in the
generated html.

A while back the entry/exit points of debugify were instrumented with
conversion functions to/from non-intrinsic-form debug-info. This is the
path of least resistance to incrementally converting parts of LLVM to
use the new format. However, it turns out that debugify registers
callbacks with the pass manager and can be fed non-intrinsic form
debug-info. Thus: this patch wraps each of the four major debugify
functions with the convertion utilities, and extends test coverage to a
test that exposes this problem.

(An alternative would be to put this code in the callback lambdas, but
then it would be fighting pass manager abstractions of what type the IR
has).

Handily debugify has been designed to record the /meaning/ of debug-info
rather than take pointers to intrinsics and the like, so the storage
mechanism for debug-info is transparent to it!

Before:
```
[----------] 65 tests from AArch64CPUTests/AArch64CPUTestFixture
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/0
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/0 (0 ms)
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/1
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/1 (0 ms)
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/2
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/2 (0 ms)
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/3
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/3 (0 ms)
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/4
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/4 (0 ms)
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/5
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/5 (0 ms)
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/6
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/6 (0 ms)
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/7
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/7 (0 ms)
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/8
...
```

After:
```
[----------] 65 tests from AArch64CPUTests/AArch64CPUTestFixture
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a34
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a34 (0 ms)
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a35
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a35 (0 ms)
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a53
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a53 (0 ms)
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a55
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a55 (0 ms)
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a510
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a510 (0 ms)
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a520
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a520 (0 ms)
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a57
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a57 (0 ms)
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a65
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a65 (0 ms)
...
```

Which improves the experience of finding and running this:
```
$ ./unittests/TargetParser/TargetParserTests --gtest_filter=AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a65
Note: Google Test filter = AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a65
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from AArch64CPUTests/AArch64CPUTestFixture
[ RUN      ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a65
[       OK ] AArch64CPUTests/AArch64CPUTestFixture.testAArch64CPU/cortex_a65 (0 ms)
[----------] 1 test from AArch64CPUTests/AArch64CPUTestFixture (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (0 ms total)
[  PASSED  ] 1 test.
```

resolves: https://github.com/llvm/llvm-project/issues/80868

When picking the source location for a branch instruction in the
CodeExtractor, we can end up picking the source location of a debugging
intrinsic. This never makes sense because any variable assignment
information (or labels) might originate from completely different
lexical scopes that have been inlined, and also makes the line tables
change between -g and -gmlt. Fix this by skipping debug intrinsics when
looking for branch source locations.

Detected because of test differences with RemoveDIs, the non-intrinsinc
form of debug-info -- fixing in intrinsic form to avoid there being
spurious test differences when we turn it on.

[SelectionDAG] Use getRegisterType instead of getTypeToTransformTo in ComputePHILiveOutRegInfo. (#80773)

Since we used getNumRegisters right before this, I think this is the
correct interface we should be using here.

I'm experimenting with making i32 legal on RISC-V 64, but using i64 for
the register type between basic blocks. This was one of the first issues
I found trying to do that.

Shortening Iota to Iot seemed strange to me.

I also remove the M from VMIota and VMIdx. The instruction for viota
does have an m at the end of it, but vid.v does not. The M didn't seem
very important for viota.

The comment and code here seems to match getTypeForExtReturn. The
history shows that at the time this code was added, similar code existed
in SelectionDAGBuilder. SelectionDAGBuiler code has since been
refactored into getTypeForExtReturn.

This patch makes FastISel match SelectionDAGBuilder.

The test changes are because X86 has customization of
getTypeForExtReturn. So now we only extend returns to i8.

Stumbled onto this difference by accident.

FastISel may create a redundant BGTZ terminal which fallthroughes.
```
  BGTZ %2:gpr32, %bb.1, implicit-def $at

bb.1.bb1:
; predecessors: %bb.0
```

The `!I->isBarrier()` check in
MipsAsmPrinter::isBlockOnlyReachableByFallthrough
will incorrectly not print a label, leading to a `Undefined temporary
symbol `
error when we try assembling the output assembly file. See the updated
`Fast-ISel/pr40325.ll` and
https://github.com/rust-lang/rust/issues/108835

In addition, the `SwitchInst` condition is too conservative and prints
many unneeded labels (see the updated tests).

Just use the generic isBlockOnlyReachableByFallthrough, updated by
commit 1995b9fe for SPARC, which also
handles MIPS.

[CallPromotionUtil] See through function alias when devirtualizing a virtual call on an alloca. (#80736)

- Extract utility function from
`DevirtModule::tryFindVirtualCallTargets` [1], which sees through an alias to a function. Call this utility function in
the WPD callsite.
- For type profiling work, this helper function will be used by indirect-call-promotion pass to find the function pointer at a specified vtable offset (an example in [2])

[1] https://github.com/llvm/llvm-project/blob/b99163fe8feeacba7797d5479bbcd5d8f327dd2d/llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp#L1069-L1082
[2] https://github.com/minglotus-6/llvm-project/blob/77a0ef12de82d11f448f7f9de6f2dcf87d9b74af/llvm/lib/Transforms/Instrumentation/IndirectCallPromotion.cpp#L347

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.