I'm not aware of any remaining overrides of this function.

While I'm here, change an outdated comment in DataflowAnalysis.h that
still
referred to `merge()`. I've made the comment more general, referring
simply to
`ValueModel`, as we shouldn't really be repeating the documentation of
that
class here anyway.

https://gitlab.com/qemu-project/qemu/-/issues/1833 was fixed by
https://gitlab.com/qemu-project/qemu/-/commit/4b3520fd93cd49cc56dfcab45d90735cc2e35af7
which was included in v8.1.1.

The buildbot is now using v8.1.3 so the test is passing.

https://lab.llvm.org/buildbot/#/builders/179/builds/9468

This replaces `SmallVector<CondState>` and emulates it.

- -------- True  False DontCare
- Values:  True  False False
- Visited: True  True  False

`findIndependencePairs()` can be optimized with logical ops.

FIXME: Specialize `findIndependencePairs()` for the single word.

For instruction xvpermi.q, only [1:0] and [5:4] bits of operands[3] are
used. The unused bits in operands[3] need to be set to 0 to avoid
causing undefined behavior.

Codegen option is passed copy by value which 138 bytes of copy and used
as read-only. Making pass by const reference.

To reduce conditional judges in the loop in `findIndependencePairs()`, I
have tried a couple of tweaks.

* Isolate the final result in `TestVectors`

`using TestVectors = llvm::SmallVector<std::pair<TestVector,
CondState>>;`
The final result was just piggybacked on `TestVector`, so it has been
isolated.

* Filter out and sort `ExecVectors` by the final result

It will cost more in constructing `ExecVectors`, but it can reduce at
least one conditional judgement in the loop.

Otherwise modules.std-module.sh.cpp test fails with following error:
    error: no member named 'atomic_signed_lock_free' in namespace 'std'
when the types are not available.

This include 2 fixes:
        1. Disallow 'f' for softfloat.
        2. Allow 'r' for softfloat.

Currently, 'f' is accpeted by clang, then LLVM meets an internal error.

'r' is rejected by LLVM by: couldn't allocate input reg for constraint
'r'.

Fixes: #64241, #63632

---------

Co-authored-by: Fangrui Song <i@maskray.me>

llvm::dwarf::getDebugNamesBucketCount directly returns the bucket count,
via return statement, but it also returns the hash count via a
parameter. This changes the function to return them both as a std::pair,
in the return statement. It also changes the name of the function to
make it clear it returns both values.

This reverts commit 86f6caa5. Unit test
was failing on a few windows build bots

mlir/lib/Target/LLVMIR/ModuleTranslation.cpp:1050:11:
error: variable 'numConstantsHit' set but not used [-Werror,-Wunused-but-set-variable]
      int numConstantsHit = 0;
          ^
mlir/lib/Target/LLVMIR/ModuleTranslation.cpp:1051:11:
error: variable 'numConstantsErased' set but not used [-Werror,-Wunused-but-set-variable]
      int numConstantsErased = 0;
          ^
2 errors generated.

We use getVectorIdxConstant() in some places and getConstant(XLenVT) or
getIntPtrConstant() in others, but getVectorIdxTy() == getPointerTy() ==
XLenVT.

This refactors RISCVISelLowering to use the former for nodes that use
getVectorIdxTy(), i.e. INSERT_SUBVECTOR, EXTRACT_SUBVECTOR,
INSERT_VECTOR_ELT and EXTRACT_VECTOR_ELT, so that we're consistent.

Forming a `ReadAdvance` with an entry in the `ValidWrites` list that is
not used by any instruction results in the entire `ReadAdvance` to be
ignored by the scheduler due to an invalid entry.

The `SchedRW` collection code only picks up `SchedWrites` that are
reachable from `Instructions`, `InstRW`, `ItinRW` and `SchedAlias`,
leaving the unreachable ones with an invalid entry (0) in
`SubtargetEmitter::GenSchedClassTables` when going through the list of
`ReadAdvances`

[MLIR][LLVM] Fix memory explosion when converting global variable bodies in ModuleTranslation (#82708)

There is memory explosion when converting the body or initializer region
of a large global variable, e.g. a constant array.

For example, when translating a constant array of 100000 strings:

llvm.mlir.global internal constant @cats_strings() {addr_space = 0 :
i32, alignment = 16 : i64} : !llvm.array<100000 x ptr<i8>> {
    %0 = llvm.mlir.undef : !llvm.array<100000 x ptr<i8>>
    %1 = llvm.mlir.addressof @om_1 : !llvm.ptr<array<1 x i8>>
%2 = llvm.getelementptr %1[0, 0] : (!llvm.ptr<array<1 x i8>>) ->
!llvm.ptr<i8>
    %3 = llvm.insertvalue %2, %0[0] : !llvm.array<100000 x ptr<i8>>
    %4 = llvm.mlir.addressof @om_2 : !llvm.ptr<array<1 x i8>>
%5 = llvm.getelementptr %4[0, 0] : (!llvm.ptr<array<1 x i8>>) ->
!llvm.ptr<i8>
    %6 = llvm.insertvalue %5, %3[1] : !llvm.array<100000 x ptr<i8>>
    %7 = llvm.mlir.addressof @om_3 : !llvm.ptr<array<1 x i8>>
%8 = llvm.getelementptr %7[0, 0] : (!llvm.ptr<array<1 x i8>>) ->
!llvm.ptr<i8>
    %9 = llvm.insertvalue %8, %6[2] : !llvm.array<100000 x ptr<i8>>
    %10 = llvm.mlir.addressof @om_4 : !llvm.ptr<array<1 x i8>>
%11 = llvm.getelementptr %10[0, 0] : (!llvm.ptr<array<1 x i8>>) ->
!llvm.ptr<i8>
    %12 = llvm.insertvalue %11, %9[3] : !llvm.array<100000 x ptr<i8>>

    ... (ignore the remaining part)
}

where @om_1, @om_2, ... are string global constants.

Each time an operation is converted to LLVM, a new constant is created.
When it comes to llvm.insertvalue, a new constant array of 100000
elements is created and the old constant array (input) is not destroyed.
This causes memory explosion. We observed that, on a system with 128 GB
memory, the translation of 100000 elements got killed due to using up
all the memory. On a system with 64 GB, 65536 elements was enough to
cause the translation killed.

There is a previous patch (https://reviews.llvm.org/D148487) which fix
this issue but was reverted for
https://github.com/llvm/llvm-project/issues/62802

The old patch checks generated constants and destroyed them if there is
no use. But the check of use for the constant is too early, which cause
the constant be removed before use.


This new patch added a map was added a map to save expected use count
for a constant. Then decrease when reach each use.
And only erase the constant when the use count reach to zero

With new patch, the repro in
https://github.com/llvm/llvm-project/issues/62802 finished correctly.

Adds a new parameter, `bool DetachProcess` with a default option of
`false`, to `llvm::sys::ExecuteNoWait`, which, when set to `true`,
executes the specified program without a controlling terminal.

Functionality added so that the module build daemon can be run without a
controlling terminal.

CodeGenInstruction has a new unsigned member EnumVal. It is not
initialized in either the class or the constructor.

This reverts commit 91791c60.

This fixes a few breakages introduced during upstreaming.

MachineIR alias analysis assumes that only bytes after the pointer will
be accessed. This is incorrect if the stride is negative.

This is causing miscompiles in our downstream after SLP started making
strided loads.

Fixes #82657

Do not include sanitizer_placement_new.h into header files, only into
source files.

Reverts llvm/llvm-project#70390

There's a bug caught by
`ScudoCombinedTestReallocateInPlaceStress_DefaultConfig.ReallocateInPlaceStress`
with gwp asan. It's an easy fix but given that this is a major change, I
would like to revert it first

Fixes erroneous usage of `bkpts` instead of `watchpoints` (probably
introduced from copying and pasting `get_target_bkpts()`).

Extra tests with unnamed bitfields for
https://github.com/llvm/llvm-project/pull/82922.

Clang was incorrectly finding the start of the exponent in a fixed point
hex literal. It would unconditionally find the first `e/E/p/P` in a
constant regardless of if it were hex or not and parser the remaining
digits as an APInt. In a debug build, this would be caught by an
assertion, but in a release build, the assertion is removed and we'd end
up in an infinite loop.

Fixes #83050

This patch inserts 1-byte counters instead of an 8-byte counters into
llvm profiles for source-based code coverage. The origial idea was
proposed as block-cov for PGO, and this patch repurposes that idea for
coverage: https://groups.google.com/g/llvm-dev/c/r03Z6JoN7d4

The current 8-byte counters mechanism add counters to minimal regions,
and infer the counters in the remaining regions via adding or
subtracting counters. For example, it infers the counter in the if.else
region by subtracting the counters between if.entry and if.then regions
in an if statement. Whenever there is a control-flow merge, it adds the
counters from all the incoming regions. However, we are not going to be
able to infer counters by subtracting two execution counts when using
single-byte counters. Therefore, this patch conservatively inserts
additional counters for the cases where we need to add or subtract
counters.

RFC:
https://discourse.llvm.org/t/rfc-single-byte-counters-for-source-based-code-coverage/75685

Summary:
The https://github.com/llvm/llvm-project/pull/83026 patch has another
use for this function. Additionally add support for the Arm instruction
barrier if this is ever used by other targets.

[flang] Fix ISO_Fortran_binding.h to work better with C++ code

This stems from working on LANL's "dopey" project --
https://github.com/lanl/dopey.

That project contains C++ code which includes the header file
"ISO_Fortran_binding.h". The dopey code wraps that include with an
'extern "C"' clause since the standard (18.5.1, paragraph 1) says that
the file" shall contain C structure definitions, typedef declarations,
...". But the clang++ compiler emits error messages objecting to the
fact that ISO_Fortran_binding.h contains templates.

This change fixes that by preceding the problematic code in
ISO_Fortran_binding.h with language linkage clauses that specify that
they contain C++ code rather than C code.

In the accompanying test, I needed to account for the fact that some
people build the compiler by doing a `make check-flang`. In this case,
the clang compiler which is required by the test will not be built.

Here's an example of a C++ program that shows the problem:
```
  extern "C" {
  #include "ISO_Fortran_binding.h"
  }
  int main() {
    return 0;
  }
```

This is a fix for commit e9cdd165 ("[docs] Remove the Packaging
"Tips" which seems to be about pre-cmake ./configure (#82958)"). The
doc was removed but not the references to it.

There are two issues here. first `ICK_Floating_Integral` were always
defaulting to `CK_FloatingToIntegral` for vectors regardless of
direction of cast. Check was scalar only so added a vec float check to
the conditional.

Second issue was float to int casts were resolving to
ICK_Integral_Promotion when they need to be resolving to
CK_FloatingToIntegral. This was fixed by changing the ordering of
conversion checks.

This fixes #82826

This PR does not include support for COMPLEX(16) intrinsics.
Note that (fp ** int) operations do not require Float128Math library,
as they are implemented via basic F128 operations,
which are supported by the build compilers' runtimes.

DWARF5 spec supports the .debug_names acceleration table. This is the
formalized version of combination of gdb-index/pubnames/types. Added
implementation of it to BOLT. It supports both monolothic and split
dwarf, with and without Type Units. It does not include parent indices.
This will be in followup PR. Unlike LLVM output this will put all the
CUs and TUs into one Module.