Follow up from PR #162147. We do not have existing !prof metadata to synthesize one for the new `select`​ .

Fixes https://lab.llvm.org/staging/#/builders/221/builds/3091

Issue #147390

This patch resolves recent regressions related to [issue
#92891](https://github.com/llvm/llvm-project/issues/92891).
It specifically enables the following types of reductions.

```llvm
define i16 @src(i32 %mask, i32 %upper, i32 range(i32 0, 65536) %lower) {
  %upper.shl = shl nuw i32 %upper, 16
  %pack = or disjoint i32 %upper.shl, %lower
  %mask.bit = and i32 %mask, 16
  %sel = lshr i32 %pack, %mask.bit
  %trunc = trunc i32 %sel to i16
  ret i16 %trunc
}
; =>
define i16 @tgt(i32 %mask, i32 %upper, i32 range(i32 0, 65536) %lower) {
  %mask.bit = and i32 %mask, 16
  %mask.bit.z = icmp eq i32 %mask.bit, 0
  %sel = select i1 %mask.bit.z, i32 %lower, i32 %upper
  %trunc = trunc i32 %sel to i16
  ret i16 %trunc
}
```

Alive2 proofs: [gJ9MpP](https://alive2.llvm.org/ce/z/gJ9MpP)

Add operators to shift left or right and insert unknown bits.

Add support for other Constant types for the mask operand.

Having a finite Depth (or recursion limit) for computeKnownBits is very
limiting, but is currently a load-bearing necessity, as all KnownBits
are recomputed on each call and there is no caching. As a prerequisite
for an effort to remove the recursion limit altogether, either using a
clever caching technique, or writing a easily-invalidable KnownBits
analysis, make the Depth argument in APIs in ValueTracking uniformly the
last argument with a default value. This would aid in removing the
argument when the time comes, as many callers that currently pass 0
explicitly are now updated to omit the argument altogether.

Reapply "IR: Remove uselist for constantdata (#137313)"

This reverts commit 5936c02c8b9c6d1476f7830517781ce8b6e26e75.

Fix checking uselists of constants in assume bundle queries

Possibly breaks the build: https://lab.llvm.org/buildbot/#/builders/24/builds/8119

This reverts commit 87f312aad6ede636cd2de5d18f3058bf2caf5651.

This is a resurrected version of the patch attached to this RFC:

https://discourse.llvm.org/t/rfc-constantdata-should-not-have-use-lists/42606

In this adaptation, there are a few differences. In the original patch, the Use's
use list was replaced with an unsigned* to the reference count in the value. This
version leaves them as null and leaves the ref counting only in Value.

Remove use-lists from instances of ConstantData (which are shared
across modules and have no operands).

To continue supporting most of the use-list API, store a ref-count in
place of the use-list; this is for API like Value::use_empty and
Value::hasNUses.  Operations that actually need the use-list -- like
Value::use_begin -- will assert.

This change has three benefits:

 1. The compiler output cannot in any way depend on the use-list order
    of instances of ConstantData.

 2. There's no use-list traffic when adding and removing simple
    constants from operand lists (although there is ref-count traffic;
    YMMV).

 3. It's cheaper to serialize use-lists (since we're no longer
    serializing the use-list order of things like i32 0).

The downside is that you can't look at all the users of ConstantData,
but traversals of users of i32 0 are already ill-advised.

Possible follow-ups:
  - Track if an instance of a ConstantVector/ConstantArray/etc. is known
    to have all ConstantData arguments, and drop the use-lists to
    ref-counts in those cases.  Callers need to check Value::hasUseList
    before iterating through the use-list.
  - Remove even the ref-counts.  I'm not sure they have any benefit
    besides minimizing the scope of this commit, and maintaining the
    counts is not free.

Fixes #58629

Co-authored-by: Duncan P. N. Exon Smith <dexonsmith@apple.com>

Alive2: https://alive2.llvm.org/ce/z/uiUzEf

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

Note: To avoid regression in
`ret_nofpclass_nopositives_copysign_nnan_flag`, the second commit takes
FMF into account.