When deciding whether to perform rounding on the significand,
the generated IR was using (width - leading zeros - 1) rather
than (width - leading zeros). This is different from how the
routine in compiler-rt does it:

    int sd = srcBits - clzSrcT(a);
    int e = sd - 1;
    if (sd > dstMantDig) {

This bug means that the following code, when built on -O0:

    #include <stdio.h>

    _BitInt(233) v_1037 = 0;

    int main(void)
    {
        v_1037 = 18014398509481982wb;
        double d = v_1037;
        printf("d = %f\n", d);

        return 0;
    }

prints "d = 9007199254740992.000000", which is incorrect.
The correct result is "d = 18014398509481982.000000".

This is refactoring preparing to move UseECMap computation to the
archive writer. We currently require writeArchive caller to pass that.
This is not practical for llvm-ar, which currently interprets at most
one passed object. For a reliable UseECMap, we need to interpret all
symbolic objects: we may have, for example, a list of x86_64 files
followed by aarch64 file, which indicates that we should use EC map for
x86_64 objects.

This commit interprets symbolic files in a separated pass, which will be
a convenient place to implement UseECMap computation in the follow up.
It also makes accessing the next member for AIX big archive offset
computation a bit easier.

We did this for if statements, but switch and loop constructs
need to do it as well.

[DAG] foldAndToUsubsat/foldSubToUSubSat - share the same SDLoc argument instead of recreating it over and over again.

Adding a tuning feature to fix
https://github.com/llvm/llvm-project/issues/84182
Generates vpdpwssd (instead of vpmaddwd + vpaddd sequence)

Reductions such as min are intrinsic procedures. This distinguishes them
from user defined reductions. Previously, the intrinsic attribute was
not set when visiting reduction clauses causing them to be missed.

wsloop-reduction-min.f90 (the other min reduction test) worked because
it contained "min" used as an intrinsic inside of the body of the
reduction. This allowed ResolveNamesVisitor::HandleProcedureName to set
the correct attribute on that Symbol.

This patch adds the support for and/or in `getFreelyInvertedImpl` using
DeMorgan's Law:
```
(~(A | B)) -> (~A & ~B)
(~(A & B)) -> (~A | ~B)
```
Alive2: https://alive2.llvm.org/ce/z/Uig8-j

for mlir fold to avoid too many overflow state check

LDDRdPtrQ was marked as `earlyclobber`, which doesn't play well with
GreedyRA (which can generate this instruction through `loadRegFromStackSlot()`).

This seems to be the same case as:

https://github.com/llvm/llvm-project/blob/a99b912c9b74f6ef91786b4dfbc25160c27d3b41/llvm/lib/Target/AVR/AVRInstrInfo.td#L1421

Closes https://github.com/llvm/llvm-project/issues/81911.

Reverts llvm/llvm-project#83251

Buildbot: https://lab.llvm.org/buildbot/#/builders/139/builds/61485

This reverts commit 7f216786 to fix
issues reported in https://github.com/llvm/llvm-project/pull/84536.

This reverts commit e4b77244 to fixx the
issues reported in https://github.com/llvm/llvm-project/pull/84536.

The test output changed after initial commit/test in
5f774619

This reverts commit ea429e19 to fix
issues reported in https://github.com/llvm/llvm-project/pull/84536#issuecomment-1999295445.

If --write-experimental-debuginfo-iterators-to-bitcode is true (default false)
and --expermental-debuginfo-iterators is also true then the new debug info
format (non-instruction records) is written to bitcode directly.

Added the following records:

    FUNC_CODE_DEBUG_RECORD_LABEL
    FUNC_CODE_DEBUG_RECORD_VALUE
    FUNC_CODE_DEBUG_RECORD_DECLARE
    FUNC_CODE_DEBUG_RECORD_ASSIGN
    FUNC_CODE_DEBUG_RECORD_VALUE_SIMPLE

The last one has an abbrev in FUNCTION_BLOCK BLOCK_INFO. Incidentally, this uses
the last value available without widening the code-length for FUNCTION_BLOCK
from 4 to 5 bits.

Records are formatted as follows:

    All DbgRecord start with:
      1. DILocation

      FUNC_CODE_DEBUG_RECORD_LABEL
        2. DILabel

      DPValues then share common fields:
        2. DILocalVariable
        3. DIExpression

        FUNC_CODE_DEBUG_RECORD_VALUE
          4. Location Metadata

        FUNC_CODE_DEBUG_RECORD_DECLARE
          4. Location Metadata

        FUNC_CODE_DEBUG_RECORD_VALUE_SIMPLE
	  4. Location Value (single)

        FUNC_CODE_DEBUG_RECORD_ASSIGN
	  4. Location Metadata
	  5. DIAssignID
	  6. DIExpression (address)
	  7. Location Metadata (address)

Encoding the DILocation metadata reference directly appeared to yield smaller
bitcode files than encoding the operands seperately (as is done with instruction
DILocations).

FUNC_CODE_DEBUG_RECORD_VALUE_SIMPLE is by far the most common DbgRecord record
in optimized code (order of 5x-10x over other kinds). Unoptimized code should
only contain FUNC_CODE_DEBUG_RECORD_DECLARE.

If the second instruction is commutable, we should be able to check
its commutable operands.

A simple RISCV fusion is contained in this PR to show the functionality
is correct, I may remove it when landing.

Fixes #82738

Fixes casts between double/float/half and i128. The pass seems to be
broken for bfloat though. I also believe we could have a better implementation
which attempts to make use the native 32-bit conversion instructions like
the 64-bit expansion does.

Blocking that signal causes inter-blocking for profilers that monitor
threads through that signal.

Update tests accordingly to use an uncaught signal.

This is a recommit of 6f3f659c with the
tests fixed.

Fix #83844 and #83561

Introduces a SubscriptOp that allows to write IR like
```
func.func @load_store(%arg0: !emitc.array<4x8xf32>, %arg1: !emitc.array<3x5xf32>, %arg2: index, %arg3: index) {
  %0 = emitc.subscript %arg0[%arg2, %arg3] : <4x8xf32>, index, index
  %1 = emitc.subscript %arg1[%arg2, %arg3] : <3x5xf32>, index, index
  emitc.assign %0 : f32 to %1 : f32
  return
}
```
which gets translated into the C++ code
```
v1[v2][v3] = v0[v1][v2];
```

To make this happen, this
- adds the SubscriptOp
- allows the subscript op as rhs of emitc.assign
- updates the emitter to print SubscriptOps

The emitter prints emitc.subscript in a delayed fashing to allow it
being used as lvalue.
I.e. while processing
```
%0 = emitc.subscript %arg0[%arg2, %arg3] : <4x8xf32>, index, index
```
it will not emit any text, but record in the `valueMapper` that the name
for `%0` is `v0[v1][v2]`, see `CppEmitter::getSubscriptName`. Only when
that result is then used (here in `emitc.assign`), that name is inserted
into the text.

llvm-project/llvm/lib/CodeGen/MachineLoopInfo.cpp:215:14:
error: lambda capture 'Reg' is not used [-Werror,-Wunused-lambda-capture]
      [this, Reg](const MachineInstr &MI) { return this->contains(&MI); });
           ~~^~~
1 error generated.

Instead of aborting interpretation right away. This way we can still
successfully evaluate such functions provided we don't reach the
Error op at all.

At the moment MachineLoopInfo has a very simple way to determine if a
use of a physical register will be invariant: if it is not a constant
value or if it's not an ignorable use, then it's not considered
invariant.

From a compile-time performance perspective this makes a lot of sense,
but it limits code that uses implicit physical registers from being
hoisted until the later MachineLICM pass (after register allocation),
which has a lot fewer opportunities to hoist.

For AArch64 SME we use an implicit physical register ($vg) to avoid
rematerialization beyond certain instructions. Doing this led to
regressions because simple expressions were no longer hoisted by Early
MachineLICM.

This patch adds some extra checks to 'isLoopInvariant' to see if any of
the defs are found in the loop. If not, we can considered it loop
invariant.

We expect the impact on compile-time to be negligible because there is
an incentive for users to reduce the need for the smstart/smstop
instructions that define $vg. In either case, we've put the
functionality under a target interface to limit this only to specific
registers.

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

The function returns a const Expr* anyway.

This is just a bit of cleanup to make the pseudo/code easier to
understand. This is based on the observation that we only need to pass
in a runtime value for 'pstate' if is actually needed for generating a
runtime check.

This is mainly for consistency across code paths, but also makes
sure that all calls use IRInstrumentationBuilder and its special
debuginfo handling.

The two remaining uses don't actually need RAUW, they just have
to erase the original instruction.

Alive2: https://alive2.llvm.org/ce/z/n_ns-W

Resolve #84608

atomicrmw xchg also accepts pointer and floating-point values. To handle
those, insert necessary casts to and from integer. This is what we do
for cmpxchg as well.

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

By doing the same thing the current interpreter does: Just passing on
the first parameter.

With the timezone information available in the CI these tests can be
enabled again.

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

atom.add.noftz.f16 is supported since SM 7.0

The section type from 9f64604e (2013)
was untested.

Clang has a custom separate pipeline integrated with libc++ that only
runs in release mode. It means that changes which touches only clang
won't run the clang tests in the configuration used by LLVM premerge and
will break it unknowingly.

getBuildAttributes is only called for ARM/RISCV object files and
`SHT_ARM_ATTRIBUTES == SHT_RISCV_ATTRIBUTES`, so the following check
`Sec.sh_type == ELF::SHT_ARM_ATTRIBUTES || Sec.sh_type == ELF::SHT_RISCV_ATTRIBUTES`
is actually fine. But the convention is to guard such processor-specific
section type checks with an e_machine test.