Remove stale branch which is unreachable with opaque pointers.

This patch updates the last few places in LLVM using findDbgValues that
don't also collect and handle DPValue objects. This largely involves
instcombine and mem2reg changes, and are largely mechanical, calling
existing utilities on collections of DPValues instead of just
DbgValuesInsts.

A variety of tests have had RemoveDIs RUN lines added to them to cover
these behaviours. We have some technical debt of the instcombine sinking
code for DPValues not being implemented yet, so I've left FIXME stubs
indicating that we intend to cover tests with RemoveDIs but haven't yet.

This fixed incorrect removal of freeze instructions.

C++20 will automatically generate an operator== with reversed operand
order, which is ambiguous with the written operator== when one argument
is marked const and the other isn't.

This operator currently triggers -Wambiguous-reversed-operator at
several usage sites in libc/test/src/__support/CPP/bitset_test.cpp,
starting with line 153.

While working on #embed, I noticed that the PR accidentally broke the
warning group but no tests failed as a result. This is adding the
missing test coverage.

The select condition ensures the disjointness here. The transform
is not valid without dropping the flag, which InstSimplify can't
do.

This patch contains two related combines:
1) If we have an scalar vector insert into the result of a
concat_vector,
   sink the insert into the operand of the concat.
2) If we have a insert of a scalar binop into a vector binop of the
   same opcode and the RHS of both are constant, perform the insert
   and then the binop.

The common theme to both is pushing inserts closer to the sources of the
computation graph. The goal is to enable forming vector bin ops from
inserts of scalar binops at the end of another vector.

For RISCV specifically, the concat_vector transform will push inserts to
smaller vectors. This will have the effect of reducing lmul for the
vslides, and usually doesn't require an additional vsetvli since
the source vectors are already working in the narrower VL.   I tried
that one as a target independent combine first, and it doesn't appear
profitable on all targets.

This is only one approach to the problem. Another idea would be to
aggressively form build_vectors and subvector inserts from the
individual scalar inserts, and then have a transform which sunk a
subvector_insert down through the concat. The advantage of the alternate
approach is that we expose parallelism in the insert sequence, even if
the source vector isn't a concat_vector. If reviewers are okay with it,
I'd like to start with this approach, and then explore that direction in
a follow up patch.

Add multi-vector SEL (x2, x4) ACLE builtins & intrinsics
Patch by: David Sherwood <david.sherwood@arm.com>

CodeGenPrepare needs to support the maintenence of DPValues, the
non-instruction replacement for dbg.value intrinsics. This means there are
a few functions we need to duplicate or replicate the functionality of:
 * fixupDbgValue for setting users of sunk addr GEPs,
 * The remains of placeDbgValues needs a DPValue implementation for sinking
 * Rollback of RAUWs needs to update DPValues
 * Rollback of instruction removal needs supporting (see github #73350)
 * A few places where we have to use iterators rather than instructions.

There are three places where we have to use the setHeadBit call on
iterators to indicate which portion of debug-info records we're about to
splice around. This is because CodeGenPrepare, unlike other optimisation
passes, is very much concerned with which block an operation occurs in and
where in the block instructions are because it's preparing things to be in
a format that's good for SelectionDAG.

Ther...

Add a test to document an existing problem in GCNRegPressure tracker.

The upward tracker does not count the registers used (16 of them) in
movrel instruction (for example V_INDIRECT_REG_WRITE_MOVREL_B32_V16).

The downward tracker counts the registers but reports a mismatch:
%0:L0000000000000C00 isn't found in LIS reported set

We're changing the operand of the or here, such that the disjoint
flag may no longer hold. Clear it.

Prep work for #73509 (missed in #73654)

This just moves towards reusing same function for both cost
estimation/codegen for buildvector.

This patch introduces a warning that is emitted when a Neon builtin is
called from a streaming function, as that situation is not supported.

Uses work by Kerry McLaughlin.

Currently, MinBWs map uses Value* as a key and stores mapping for each
value to be demoted. It make is it hard to get the actual MinBWs value
for the buildvector scalars(constants), since same constant might be
  used in different nodes with the different MinBWs values/decisions.
Also, it consumes extra memory for the vectorized values/instructions
 from the same nodes.
Better to map actual nodes. It fixes the bitwidth data fetching for
buildvector scalars and improves memory consumption/analysis time for
other instructions.

1. Add TB_BCAST_SH for FP16
2. Auto-gen 4 broadcast tables BroadcastTable[1-4]

issue: https://github.com/llvm/llvm-project/issues/66360

Fixes #73787

Not doing so lead to us making use of a register after the call, which
has been clobbered by the call.

Added an MIR test that runs only the pseudo expansion pass.

We now add -latomic whenever we detect that it's supported on the platform,
and we mark the tests as UNSUPPORTED on platforms where non-lockfree
atomics are not supported.

Following up on #73777, this fixes the predicate for the SVE-specific
FEAT_CPA instructions to require SVE instead of SVE or SME. These
instructions should not be availabe if only SME is enabled.

This fixes a few issues present in the current version:
1) The macro doesn't enforce the default visibility on exported
   functions, causing compilation to fail when using
   `-fvisibility=hidden`
2) Not all functions are exported
3) Sometimes the macro ended up weirdly interleaved with `extern "C"`
   declarations

I'm occasionally using this to find cases where computeKnownBits()
and SimplifyDemandedBits() went out of sync.

This option is not enabled by default (even under EXPENSIVE_CHECKS)
because it has a number of known failures in our tests. The reason
for this failures is that computeKnownBits() performs recursive
queries using the original context instruction, while
SimplifyDemandedBits() uses the current instruction. This is
something we can improve, but using the original context wouldn't
always be safe in this context (when non-speculatable instructions
are involved).

This change has no meaningful effect on the compiler, although it has a
functional effect of dbg.value intrinsics being printed differently. The
tail-call flag is meaningless for debug-intrinsics and doesn't serve a
purpose, it's just extra baggage that dbg.values are built on top of.
Some facilities create debug-intrinsics with the flag, others don't.
However, the RemoveDIs project to represent debug-info without
intrinsics doesn't have a corresponding flag, which can cause spurious
test differences.

Specifically: we can convert a dbg.value to a DPValue, run an
optimisation pass, then convert the DPValue back to dbg.value form.
Right now, we always set the "tail" flag when converting it back. This
causes the auto-update-tests script to fail sometimes because in one
mode (dbg.value) intrinsics might not have a tail flag, but in the other
they do have a tail flag. Consistently picking one or the other in the
conversion routine doesn't help, because the rest of LLVM is
inconsistent about it anyway.

Thus: whenever we make a dbg.value intrinsic, create it as a tail call,
so that we get consistent output behaviours no matter which debug-info
mode we're in, DPValue or dbg.value. No tests fail as a result of this
patch because the extra 'tail' generated in numerous tests is
automatically ignored by FileCheck as being leading-rubbish before the
CHECK match.

The IR instructions include:
- Binary Operations: add fadd sub fsub mul fmul udiv sdiv fdiv
- Bitwise Binary Operations: shl lshr ashr

We were allowing extra immediate arguments, and only bothering to check
if registers were implicit or not.

Also consolidate extra operand checks in verifier, to make this
testable. We had 3 different places checking if you were trying to build
an instruction with more operands than allowed by the definition. We had
an assertion in addOperand, a direct check in the MIRParser to avoid the
assertion, and the machine verifier checks. Remove the assert and parser
check so the verifier can provide a consistent verification experience,
which will also handle instructions modified in place.

In practice this is already true, and having this as an explicit
guarantee is useful for #72912. I don't think there is any good
reason why we would want to produce incorrect KnownBits results
for non-demanded bits.

We were using this helper in single-use demanded bits but not
multi-use demanded bits.

This fixes an assertion failure when asserting consistency between
computeKnownBits() and SimplifyDemandedBits().

FileCheck was previously missing while moving to UTC, as part of
regenerating other tests within InstCombine.

It already used it internally, make the public API use it as well.

Because we're storing some extra debug-info information in the iterator
class, we need to insert new LICM-created stores using such iterators.
Switch LICM to storing iterators instead of pointers when it promotes
variables in loops, add a test for the desired behaviour, and enable
RemoveDIs instrumentation on a variety of other LICM tests for good
measure.

(This would appear to be the only pass in LLVM that needs to store
iterators on the heap).

For parity with computeKnownBits(). This came up when adding a
consistency assertion.

Once this is submitted we can remove `include/__support/bit.h` that
duplicates some of this functionality.

Here's a problem for the RemoveDIs project to make debug-info not be
stored in instructions -- in the following sequence:
    dbg.value(foo
    %bar = add i32 ...
    dbg.value(baz
It's possible for rare passes (only CodeGenPrepare) to remove the add
instruction, and then re-insert it back in the same place. When
debug-info is stored in instructions and there's a total order on "when"
things happen this is easy, but by moving that information out of the
instruction stream we start having to do manual maintenance.

This patch adds some utilities for re-inserting an instruction into a
sequence of DPValue objects. Someday we hope to design this away, but
for now it's necessary to support all the things you can do with
dbg.values. The two unit tests show how DPValues get shuffled around
using the relevant function calls. A follow-up patch adds
instrumentation to CodeGenPrepare.