Summary:
These runtime calls don't seem to be supported anymore, disable them for
now.

[SPIR-V] improve performance of Module Analysis stage in the part of processing "other instructions" (#76047)

The goal of this PR is to fix an issue when Module Analysis stage is not
able to complete processing of a really big LLVM source:
https://github.com/llvm/llvm-project/issues/76048.

There is an example of a bulky LLVM source:
https://github.com/KhronosGroup/SPIRV-LLVM-Translator/blob/main/test/SpecConstants/long-spec-const-composite.ll

Processing of this file with
`llc -mtriple=spirv64-unknown-unknown -O0 long-spec-const-composite.ll
-o long-spec-const-composite.spvt`
to produce SPIR-V output using LLVM SPIR-V backend takes too long, and
I've never been able to see it actually completes. After the patch from
this PR applied elapsed time for me is ~30 sec.

The fix changes underlying data structure to be `std::set` to trace
instructions with identical operands instead of the existing approach of
the `findSameInstrInMS()` function.

This has to be specified in the string because otherwise we'd get the
lambda's name, and I incorrectly used the name of the calling function here.

Summary:
This causes warnings because it is already a temporary and does not need
to be moved.

The `irdl.base` op represent an attribute constraint that will check
that the
base of a type or attribute is the expected one (e.g. `IntegerType`) .

Example:

```mlir
irdl.dialect @cmath {
  irdl.type @complex {
    %0 = irdl.base "!builtin.integer"
    irdl.parameters(%0)
  }

  irdl.type @complex_wrapper {
    %0 = irdl.base @complex
    irdl.parameters(%0)
  }
}
```

The above program defines a `cmath.complex` type that expects a single
parameter, which is a type with base name `builtin.integer`, which is
the
name of an `IntegerType` type.
It also defines a `cmath.complex_wrapper` type that expects a single
parameter, which is a type of base type `cmath.complex`.

Address review comments in #76709

Add `NoCD8` to class `ITy`, and rewrite the promoted instructions with
`ITy` to avoid unexpected incorrect encoding about `NoCD8`.

Error message

```
*** Bad machine code: Illegal virtual register for instruction ***
- function:    test__blsi_u32
- basic block: %bb.0  (0x7a61208)
- instruction: %5:gr32 = MOV32r0 implicit-def $eflags
- operand 0:   %5:gr32
Expected a GR32_NOREX2 register, but got a GR32 register
```

Reported by RKSimon in #77433

The failure is b/c compiler emits a MOV32r0 with operand GR32 when
fast-isel is enabled.

```
// X86FastISel.cpp
Register SrcReg = fastEmitInst_(X86::MOV32r0, &X86::GR32RegClass)
```

However, before this patch, compiler only allows GR32_NOREX operand
b/c MOV32r0 is a pseudo instruction. In this patch, we relax the
register class of the operand to GR32 b/c MOV32r0 is always expanded
to XOR32rr, which can use EGPR.

The bug was not introduced by #77433 but caught by it.

In particular, we have internal customers that would like to use nanf
and
scalbnf.

The differences between various entrypoint files can be checked via:

    $ comm -3 <(grep libc\.src path/to/entrypoints.txt | sort) \
       <(grep libc\.src path/to/other/entrypoints.txt | sort)

These were fixed properly by f1f1875c.

- Revert "[libc] temporarily set -Wno-shorten-64-to-32 (#77396)"
- Revert "[libc] make off_t 32b for 32b arm (#77350)"

This fixes missing inlined function names when formatting frame and the
`Block` in `SymbolContext` is a lexical block (e.g.
`DW_TAG_lexical_block` in Dwarf).

This is a regression test for a miscompile that would have been
introduced by an upcoming patch.

Summary:
The linker wrapper's job is to sort various embedded inputs into a list
of files that participate in a single link job. So far, this has been
completely 1-to-1, that is, each input file participates in exactly one
link job. However, support for AMD's target-id requires that one input
file may participate in multiple link jobs. For example, if given a
`gfx90a` static library and a `gfx90a:xnack+` object file input, we
should link the gfx90a` target into the `gfx90a:xnack+` job. These are
considered separate CPUs that can be mutually linked more or less.

This patch adds the necessary logic to make this happen. It primarily
reworks the logic to copy relevant input files into a separate list. So,
it moves construction of the final list of link jobs into the extraction
phase. We also need to copy the files in the case that it is needed more
than once, as the entire workflow expects ownership of said file.

Clang stopped doing this late 2021 back in 33315ef3, and no other
frontent does this, so stop doing it.

Since most of the operations in the `math` dialect don't have
low-precision implementations, add the -math-legalize-to-f32 pass that
goes through and brackets low-precision math funcitons (like `math.sin
%0 : f16`) with `arith.extf` and `arith.truncf`. This preserves the
original semantics of the math operation but allows lowering to proceed.

Versions of this lowering are already implicitly present in some passes,
like ConvertGPUToROCDL. However, because those are implicit rewrites,
they hide the floating-point extension and truncation, preventing anyone
from writing passes that operate on those implitic extf/truncf pairs.

Exposing this legalization explicitly is needed to allow lowening 8-bit
floats on AMD GPUs, as the implementation of extf and truncf on that
platform requires the complex logic found in ArithToAMDGPU, which runs
before the GPU to ROCDL lowering.

Clean-up of the algorithm that assigns MC/DC True/False control-flow
condition IDs when constructing an MC/DC decision region. This patch
creates a common API for setting/getting the condition IDs, making the
binary logical operator visitor functions much cleaner.

This patch also fixes issue
https://github.com/llvm/llvm-project/issues/77873 in which a record's
control flow map can be malformed due to an incorrect calculation of the
True/False condition IDs.

We do the same for the analogous transform in DAGCombine, but this case
was missed in the recent patch which added support for zext nneg.

Sorry for the lack of test coverage. Not sure how to exercise this piece
of logic. It appears to have only minimal impact on LIT tests (only
test/CodeGen/X86/wide-scalar-shift-by-byte-multiple-legalization.ll),
and even then, the changes without it appear uninteresting. Maybe we
should remove this transform instead?

After the removal of the OpenMP early outlining MLIR pass in #67319, the
`EarlyOutliningInterface` stopped doing any useful work. It used to be
necessary to tie the name of the function from which a target region was
outlined to that new function, so it would be used when translating to
LLVM IR in place of the outlined function's name.

This is not necessary anymore, so this patch removes all references to
this interface and uses of the `omp.outline_parent_name` discardable
attribute in tests.

When merging blocks, if the previous block has no any branch instruction
and has one successor, the successor may be SEH landing pad and the
block will always raise exception and nerver fall through to next block.
We can not merge them in such case. isSuccessor should be used to
confirm it can fall through to next block.

We need to look at the chain of declarations to initialize the right
field.

Fixes oversight in commit 8ecbb040 in which
FileID was not being set when creating a new MC/DC DecisionRegion.

The template function call CheckDescriptorEqInt((exitStat.get(), 127) is
deduced to have INT_T equal to std::int32_t instead of std::int64_t, but
the length descriptor points to a 64-byte storage. The comparison does
not work in a big endian.

Co-authored-by: Mark Danial <mark.danial@ibm.com>

When running the `flang/test/HLFIR/simplify-hlfir-intrinsics.fir` test
case on AIX we encounter issues building op as they are not found in the
mlir context:
```
LLVM ERROR: Building op `arith.subi` 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
LLVM ERROR: Building op `hlfir.yield_element` 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
LLVM ERROR: Building op `hlfir.yield_element` 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


```
The issue is caused by the "Merge disjoint stack slots" pass and the
error is not present if the source is built with `-mllvm
--no-stack-coloring`

Thanks to investigation by @stefanp-ibm we found that "the
initializer_list {inputIndices[1], inputIndices[0]} has a lifetime that
only exists for the range of the constructor for ValueRange. Once we get
to stack coloring we merge the stack slot for that element with another
stack slot and then it gets overwritten which corrupts
transposedIndices"

The changes below prevents the corruption of transposedIndices and
passes the test case.

Co-authored-by: Mark Danial <mark.danial@ibm.com>

FmtAlign::fill() accepts a uint32_t variable while the usages operate on
size_t values. On some platform / compiler combinations, this ends up
being a narrowing conversion. Fix this by changing the function's signature.
This was first seen on MSVC x86.

Co-authored-by: Orest Chura <orest.chura@intel.com>

This helps ensure the encoding details are next to the EVEX tag

Noticed while preparing to add more constant commenting as part of #73783 and #71078

`ValueAsMetadata::handleRAUW` is a mechanism to replace all metadata
referring to one value by a different value.

Relax an assert that used to enforce the old and new value to have the
same type.
This seems to be a sanity plausibility assert only, as the
implementation actually supports mismatching types.

This is motivated by a downstream mechanism where we use poison
ValueAsMetadata values to annotate pointee types of opaque pointer
function arguments.

When replacing one type with a different one to work around DXIL vs LLVM
incompatibilities, we need to update type annotations, and handleRAUW is
more efficient than creating new MD nodes.

Everytime an extension is added, this test will need to have the negative
extension appended to multiple CHECK lines where we're overriding the arch.
This is quite time consuming since it needs to be in the right order, so this
replaces the explicit list of negative extensions with a regexp instead.

Typo in test: openmp/libomptarget/test/offloading/fortran/basic-target-parallel-do.f90

Similar to `transform.get_result`, except it returns a handle to the
operand indicated by a positional specification, same as is defined for
the linalg match ops.

Additionally updates `get_result` to take the same positional specification.
This makes the use case of wanting to get all of the results of an
operation easier by no longer requiring the user to reconstruct the list
of results one-by-one.

To avoid any possible confusion with the notion of pure function and the
gnu::pure attribute.

Added test which proves that end-to-end compilation of `omp target
parallel do` costruct is successful for Flang compiler.

Check for DEFAULT_SYSROOT, because when it is set -isysroot has no
effect.

In CheckConstant(), consider that in C++98 const variables may not be read at all, and diagnose that accordingly.

Support new amdgcn_global_load_tr instructions for load with transpose.

* MC layer support for GLOBAL_LOAD_TR_B64/GLOBAL_LOAD_TR_B128
* Intrinsic int_amdgcn_global_load_tr
* Clang builtins amdgcn_global_load_tr*

This patch brings back the basic support for C by inserting the required
for value printing runtime only when we are in C++ mode. Additionally,
it defines a new overload of operator placement new because we can't
really forward declare it in a library-agnostic way.

Fixes the issue described in llvm/llvm-project#69072.

Just a minimal readability improvement that we overlooked during
refactoring.