Fix a few unitialized class members in MLIR (NFC)

Flagged by Coverity.

[SelectionDAG] Use KnownBits::countMinSignBits() to simplify the end of ComputeNumSignBits.

This matches what is done in ValueTracking.cpp

Reviewed By: RKSimon, foad

Differential Revision: https://reviews.llvm.org/D116423

[RISCV][LegalizeIntegerTypes] Teach PromoteSetCCOperands not to sext i32 comparisons for RV64 if the promoted values are already zero extended.

This is similar to what is done for targets that prefer zero extend
where we avoid using a zero extend if the promoted values are sign
extended.

We'll also check for zero extended operands for ugt, ult, uge, and ule when the
target prefers sign extend. This is different than preferring zero extend, where
we only check for sign bits on equality comparisons.

Reviewed By: RKSimon

Differential Revision: https://reviews.llvm.org/D116421

Remove redundant return after return in CodegenStrategy (NFC)

Reported by Coverity

[mlir][LLVMIR] Add `llvm.eh.typeid.for` intrinsic

MLIR already exposes landingpads, the invokeop and the personality function on LLVM functions. With this intrinsic it should be possible to implement exception handling via the exception handling mechanisms provided by the Itanium ABI.

Differential Revision: https://reviews.llvm.org/D116436

[AMDGPU] Remove unused declarations fold_exp* and fold_log* (NFC)

[AMDGPU] Remove replaceWithNative (NFC)

The function was introduced without any use on Aug 11, 2017 in commit
7f37794ebd2c6c36224597800e4d1e5a99ad80e9.

[X86] Remove unused declaration getTileStoreShape (NFC)

[Hexagon] Use range-based for loops (NFC)

fix test so it doesn't use nonnull assumes on non-pointers
The IR verifier should probably catch this. Alive2 did, though.

[CodeGen] Remove unused forward declarations (NFC)

[Scalar] Remove a redundant declaration (NFC)

InitializePasses.h contains the proper declaration.

Identified with readability-redundant-declaration.

[clang-tidy] Use nullptr instead of 0 or NULL (NFC)

Identified with modernize-use-nullptr.

[InstSimplify] fold or-nand-xor

~(A & B) | (A ^ B) --> ~(A & B)

https://alive2.llvm.org/ce/z/hXQucg

[InstSimplify] add tests for or-nand-xor; NFC

[flang] Use `GNUInstallDirs` to support custom installation dirs.

Extracted from D99484. My new plan is to start from the outside and work
inward.

Reviewed By: stephenneuendorffer

Differential Revision: https://reviews.llvm.org/D115569

[lld][CMake] Use `GNUInstallDirs` to support custom installation dirs

Extracted from D99484. My new plan is to start from the outside and work
inward.

Reviewed By: stephenneuendorffer

Differential Revision: https://reviews.llvm.org/D115568

[clang-tools-extra] Remove unused using (NFC)

Identified by misc-unused-using-decls.

[Analysis] Remove unused forward declarations (NFC)

[ARM] Introduce an empty "armv8.8-a" architecture.

This is the first commit in a series that implements support for
"armv8.8-a" architecture. This should contain all the necessary
boilerplate to make the 8.8-A architecture exist from LLVM and Clang's
point of view: it adds the new arch as a subtarget feature, a definition
in TargetParser, a name on the command line, an appropriate set of
predefined macros, and adds appropriate tests. The new architecture name
is supported in both AArch32 and AArch64.

However, in this commit, no actual _functionality_ is added as part of
the new architecture. If you specify -march=armv8.8a, the compiler
will accept it and set the right predefines, but generate no code any
differently.

Differential Revision: https://reviews.llvm.org/D115694

[NFC][SVE] Minor reorder of some AArch64ISD nodes and ISel patterns.

[LV] Turn check for unexpected VF into assertion (NFC).

VF should always be non-zero in widenIntOrFpInduction. Turn check into
assertion.

[MIPS] Add -mfix4300 flag to enable vr4300 mulmul bugfix pass

Early revisions of the VR4300 have a hardware bug where two consecutive
multiplications can produce an incorrect result in the second multiply.
This revision adds the `-mfix4300` flag to llvm (and clang) which, when
passed, provides a software fix for this issue.

More precise description of the "mulmul" bug:
```
mul.[s,d] fd,fs,ft
mul.[s,d] fd,fs,ft  or  [D]MULT[U] rs,rt
```

When the above sequence is executed by the CPU, if at least one of the
source operands of the first mul instruction happens to be `sNaN`, `0`
or `Infinity`, then the second mul instruction may produce an incorrect
result. This can happen both if the two mul instructions are next to each
other and if the first one is in a delay slot and the second is the first
instruction of the branch target.

Description of the fix:
This fix adds a backend pass to llvm which scans for mul instructions in
each basic block and inserts a nop whenever the following conditions are
met:

 - The current instruction is a single or double-precision floating-point
   mul instruction.
 - The next instruction is either a mul instruction (any kind) or a branch
   instruction.

Differential Revision: https://reviews.llvm.org/D116238

[AMDGPU] Regenerate checks for waitcnt-overflow.mir

[lldb/qemu] Support setting arg0 of the debugged program

Just what it says on the box.

[RISCV] Use MxListW instead of MxList[0-5]. NFC

Better to use the named list instead of assuming the size of MxList.

[RISCV] Use defvar to simplify some code. NFC

Rather than wrapping a def around a list, we can just make a defvar
of the list.

[RISCV] Use constant pool for large integers

For large integers (for example, magic numbers generated by
TargetLowering::BuildSDIV when dividing by constant), we may
need about 4~8 instructions to build them.
In the same time, it just takes two instructions to load
constants (with extra cycles to access memory), so it may be
profitable to put these integers into constant pool.

Reviewed By: asb, craig.topper

Differential Revision: https://reviews.llvm.org/D114950

[RISCV] Fix incorrect cases of vmv.s.f in the VSETVLI insert pass.

Fix incorrect cases of vmv.s.f and add test cases for it.

Differential Revision: https://reviews.llvm.org/D116432

[mlir] Allow IntegerAttr to parse zero width integers.

https://reviews.llvm.org/D109555 added support to APInt for this, so the special case to disable it is no longer valid. It is in fact legal to construct these programmatically today, and they print properly but do not parse.

Justification: zero bit integers arise naturally in various bit reduction optimization problems, and having them defined for MLIR reduces special casing.

I think there is a solid case for i0 and ui0 being supported. I'm less convinced about si0 and opted to just allow the parser to round-trip values that already verify. The counter argument is that the proper singular value for an si0 is -1. But the counter to this counter is that the sign bit is N-1, which does not exist for si0 and it is not unreasonable to consider this non-existent bit to be 0. Various sources consider it having the singular value "0" to be the least surprising.

Reviewed By: lattner

Differential Revision: https://reviews.llvm.org/D116413

[asan] Additionnal prologue decoding for WinSDK 10.0.22000

Fixes interception of atoi() entry point.

[Sema] a[x] has type T when a has type T* or T[], even when T is dependent

This more precise type is useful for tools, e.g.
fixes https://github.com/clangd/clangd/issues/831

Differential Revision: https://reviews.llvm.org/D107275

[ELF] Switch cNamedSections to SmallVector. NFC

Make it smaller

[LegalizeIntegerTypes] Rename NewLHS/NewRHS arguments to DAGTypeLegalizer::PromoteSetCCOperands. NFC

The 'New' only makes sense in the context of these being
output arguments, but they are also used as inputs first.
Drop the 'New' and just call them LHS/RHS.

Factored out of D116421.

[InstrProf] Mark counters as used in debug correlation mode

In debug info correlation mode we do not emit the data globals so we
need to explicitly mark the counter globals as used so they don't get
stripped.

Reviewed By: kyulee

Differential Revision: https://reviews.llvm.org/D115981

[mlir][Linalg] Change signature of `get(Parallel/Reduce/Window)Dims` method.

These method currently takes a SmallVector<AffineExpr> & as an
argument to return the dims as AffineExpr. This creation of
AffineExpr objects is unnecessary.

Differential Revision: https://reviews.llvm.org/D116422

[lld][docs] Update _templates/indexsidebar.html after Bugzilla->GitHub issue migration

[SLP][NFC]Fix non-determinism in reordering, NFC.

Need to clear CurrentOrder order mask if it is determined that
extractelements form identity order and need to use a vector-like
construct when iterating over ordered entries in the reorderTopToBottom
function.

[Hexagon] Generate HVX/FP arithmetic instructions

Co-authored-by: Anirudh Sundar Subramaniam <quic_sanirudh@quicinc.com>
Co-authored-by: Sumanth Gundapaneni <sgundapa@quicinc.com>
Co-authored-by: Joshua Herrera <joshherr@quicinc.com>

[libc++][NFC] Fix incorrect synopsis in transform_view test

[mlir][arith] fixing dependencies on memref/arith

[Hexagon] Generate HVX/FP compare instructions

Co-authored-by: Anirudh Sundar Subramaniam <quic_sanirudh@quicinc.com>

[ELF][LTO] Cache symbol table of lazy BitcodeFile

Similar to D62188: a BitcodeFile's symbol table may be iterated twice, once in
--start-lib (lazy) state, and once in the non-lazy state. This patch
makes `parseLazy` save `symbols[i]` so that the non-lazy state does not need to
re-insert to the global symbol table. Avoiding a redundant `saver.save` may save
memory.

`Maximum resident set size (kbytes)` for a large --thinlto-index-only link:

* without the patch: 10164000
* with the patch: 10095716 (0.6% decrease)

Note: we can remove `saver.save` if `BitcodeCompiler::add` does not transfer the ownership
of `f.obj` in `checkError(ltoObj->add(std::move(f.obj), resols));`.

Reviewed By: tejohnson

Differential Revision: https://reviews.llvm.org/D116390

[RISCV] Add support for STRICT_LRINT/LLRINT/LROUND/LLROUND. Tests for other strict intrinsics.

This patch adds isel support for STRICT_LRINT/LLRINT/LROUND/LLROUND.

It also adds test cases for f32 and f64 constrained intrinsics that
correspond to the intrinsics in float-intrinsics.ll and
double-intrinsics.ll. Support for promoting the integer argument of
STRICT_FPOWI was added.

I've skipped adding tests for f16 intrinsics, since we don't have libcalls
for them and we have inconsistent support for promoting them in LegalizeDAG.
This will need to be examined more closely.

Reviewed By: asb

Differential Revision: https://reviews.llvm.org/D116323

[Bazel] Make mlir:MemRefOpsTdFiles depend on :ArithmeticOpsTdFiles

[MLIR] Add explicit `using` to disambiguate between multiple implementations from base classes (NFC)

Both of DenseElementsAttr and ElementsAttrTrait define the method of
getElementType, this commit makes it available on
DenseIntOrFPElementsAttr and DenseStringElementsAttr.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D116389

[InferAttrs] Give strnlen the same attributes as strlen

This moves the only string function out of the big list of math funcs.
And let's us CSE strnlen calls.

[ELF][LTO] Call madvise(MADV_DONTNEED) on MemoryBuffer instances

@tejohnson noticed that freeing MemoryBuffer instances right before
`lto->compile` can save RSS, likely because the memory can be reused by
LTO indexing (e.g. ThinLTO import/export lists).).

For ELFFileBase instances, symbol and section names are backed by MemoryBuffer,
so destroying MemoryBuffer would make some infrequent passes (parseSymbolVersion,
reportBackrefs) crash and make debugging difficult.
For a BitcodeFile, its content is completely unused, but destroying its
MemoryBuffer makes the buffer identifier inaccessible and may introduce
constraints for future changes.
This patch leverages madvise(MADV_DONTNEED) which achieves the major gain
without the latent issues.

`Maximum resident set size (kbytes): ` for a large --thinlto-index-only link:

* current behavior: 10146104KiB
* destroy MemoryBuffer instances: 8555240KiB
* madvise(MADV_DONTNEED) just bitcodeFiles  and lazyBitcodeFiles: 8737372KiB
* madvise(MADV_DONTNEED) all MemoryBuffers: 8739796KiB  (16% decrease)

Depends on D116366

Reviewed By: tejohnson

Differential Revision: https://reviews.llvm.org/D116367

[MLIR] Move AtomicRMW into MemRef dialect and enum into Arith

Per the discussion in https://reviews.llvm.org/D116345 it makes sense
to move AtomicRMWOp out of the standard dialect. This was accentuated by the
need to add a fold op with a memref::cast. The only dialect
that would permit this is the memref dialect (keeping it in the standard dialect
or moving it to the arithmetic dialect would require those dialects to have a
dependency on the memref dialect, which breaks linking).

As the AtomicRMWKind enum is used throughout, this has been moved to Arith.

Reviewed By: Mogball

Differential Revision: https://reviews.llvm.org/D116392

[Support] Expand `<CFGDIR>` as the base directory in configuration files.

Extends response file expansion to recognize `<CFGDIR>` and expand to the
current file's directory. This makes it much easier to author clang config
files rooted in portable, potentially not-installed SDK directories.

A typical use case may be something like the following:

```
# sample_sdk.cfg
--target=sample
-isystem <CFGDIR>/include
-L <CFGDIR>/lib
-T <CFGDIR>/ldscripts/link.ld
```

Reviewed By: sepavloff

Differential Revision: https://reviews.llvm.org/D115604

[Support] Add MemoryBuffer::dontNeedIfMmap

On *NIX systems, this API calls madvise(MADV_DONTNEED) on read-only file mappings.
It should not be used on a writable buffer.
The API is used to implement ld.lld LTO memory saving trick (D116367).

Note: on read-only file mappings, Linux's MADV_DONTNEED semantics match POSIX
POSIX_MADV_DONTNEED and BSD systems' MADV_DONTNEED.

On Windows, VirtualAllocEx MEM_COMMIT/MEM_RESET have similar semantics
but are unfortunately not drop-in replacements. dontNeedIfMmap is currently a no-op.

Reviewed By: aganea

Differential Revision: https://reviews.llvm.org/D116366

[docs][llvm-profdata] Prefer double-dash long options

To match the `--help` message and most other utilities.

While here, change `option:: -output=output` to `option:: --output=<output>` and
omit the value name for the short options (convention of other utilities).

Reviewed By: snehasish

Differential Revision: https://reviews.llvm.org/D116353

[Hexagon] Explicitly use integer types when rescaling a mask

[Hexagon] Handle HVX/FP {masked,wide} loads/stores

Co-authored-by: Rahul Utkoor <quic_rutkoor@quicinc.com>
Co-authored-by: Anirudh Sundar Subramaniam <quic_sanirudh@quicinc.com>

Revert "[lld] Add support for other demanglers other than Itanium"

This reverts commit e60d6dfd5acdc821d391ad5af2c706397bdfd36a.

clang-ppc64le-rhel buildbot failed (https://lab.llvm.org/buildbot#builders/57/builds/13424):

    tools/lld/MachO/CMakeFiles/lldMachO.dir/Symbols.cpp.o: In function `lld::demangle(llvm::StringRef, bool)':
    Symbols.cpp:(.text._ZN3lld8demangleEN4llvm9StringRefEb[_ZN3lld8demangleEN4llvm9StringRefEb]+0x90): undefined reference to `llvm::demangle(std::string const&)'

[Hexagon] Fix isTypeForHVX to recognize floating point types

Co-authored-by: Sumanth Gundapaneni <sgundapa@quicinc.com>

[mlir] Change SCF/Complex to prefixed (NFC)

See
https://llvm.discourse.group/t/psa-ods-generated-accessors-will-change-to-have-a-get-prefix-update-you-apis/4476

[lld] Add support for other demanglers other than Itanium

LLVM core library supports demangling other mangled symbols other than itanium,
such as D and Rust. LLD should use those demanglers in order to output pretty
demangled symbols on error messages.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D116279

[InstCombine] fold opposite shifts around an add

((X << C) + Y) >>u C --> (X + (Y >>u C)) & (-1 >>u C)

https://alive2.llvm.org/ce/z/DY9DPg

This replaces a shift with an 'and', and in the case
where the add has a constant operand, it eliminates
both shifts.

As noted in the TODO comment, we already have this fold when
the shifts are in the opposite order (and that code handles
bitwise logic ops too).

Fixes #52851

Revert "[InstCombine] fold opposite shifts around an add"

This reverts commit 2e3e0a5c288041745f88a06e66a831c236a3bb1f.
Some unintended diffs snuck into this patch.

[InstCombine] fold opposite shifts around an add

((X << C) + Y) >>u C --> (X + (Y >>u C)) & (-1 >>u C)

https://alive2.llvm.org/ce/z/DY9DPg

This replaces a shift with an 'and', and in the case
where the add has a constant operand, it eliminates
both shifts.

As noted in the TODO comment, we already have this fold when
the shifts are in the opposite order (and that code handles
bitwise logic ops too).

Fixes #52851

[Hexagon] Handle HVX/FP shuffles, insertion and extraction

Co-authored-by: Anirudh Sundar Subramaniam <quic_sanirudh@quicinc.com>

Revert "[Hexagon] Don't build two halves of HVX vector in parallel"

This reverts commit ba07f300c6d67a2c6dde8eef216b7a77ac4600bb.

A build-vector sequence is made of pairs: rotate+insert. When constructing
a single vector, this results in a chain of 2*N instructions. The rotate
operation is a permute operation, but the insert uses a multiplication
resource: insert and rotate can execute in the same cycle, but obviously
they cannot operate on the same vector. The original halving idea is still
beneficial since it does allow for insert/rotate overlap, and for hiding
insert's latency.

[NFC] Pre-commit NewGVN tests for wrong phi(undef, X) optimization

[mlir][vector] Fix illegal vector.transfer + tensor.insert/extract_slice folding

vector.transfer operations do not have rank-reducing semantics.

Bail on illegal rank-reduction: we need to check that the rank-reduced
dims are exactly the leading dims. I.e. the following is illegal:
```
   %0 = vector.transfer_write %v, %t[0,0], %cst :
     vector<2x4xf32>, tensor<2x4xf32>
   %1 = tensor.insert_slice %0 into %tt[0,0,0][2,1,4][1,1,1] :
     tensor<2x4xf32> into tensor<2x1x4xf32>
```

Cannot fold into:
```
   %0 = vector.transfer_write %v, %t[0,0,0], %cst :
     vector<2x4xf32>, tensor<2x1x4xf32>
```
For this, check the trailing `vectorRank` dims of the insert_slice result
tensor match the trailing dims of the inferred result tensor.

Differential Revision: https://reviews.llvm.org/D116409

[GVN] Set phi entries of unreachable predecessors to poison instead of undef
This matches NewGVN's behavior.

[lldb/qemu] More flexible emulator specification

This small patch adds two useful improvements:
- allows one to specify the emulator path as a bare filename, and have
  it be looked up in the PATH
- allows one to leave the path empty and have the filename be derived
  from the architecture.

[NFC] Pre-commit test for InstSimplify phi(poison)

[LoopFlatten] Move it to a LoopPassManager

In D109958 it was noticed that we could optimise the pipeline and avoid
rerunning LoopSimplify/LCSSA for LoopFlatten by moving it to a LoopPassManager.

Differential Revision: https://reviews.llvm.org/D110057

[NewGVN][NFC] Add test for x + poison -> poison

[InstSimplify] add 'x + poison -> poison' (needed for NewGVN)

[lldb] Remove lldbtest.getBuildFlags

It was being used only in some very old tests (which pass even without
it) and its implementation is highly questionable.

These days we have different mechanisms for requesting a build with a
particular kind of c++ library (USE_LIB(STD)CPP in the makefile).

[Opaqueptrs][IR Serialization] Improve inlineasm [de]serialization

The bitcode reader expected that the pointers are typed,
so that it can extract the function type for the assembly
so `bitc::CST_CODE_INLINEASM` did not explicitly store said function type.

I'm not really sure how the upgrade path will look for existing bitcode,
but i think we can easily support opaque pointers going forward,
by simply storing the function type.

Reviewed By: #opaque-pointers, nikic

Differential Revision: https://reviews.llvm.org/D116341

[BitcodeReader] `bitc::CST_CODE_INLINEASM`: un-hardcode offsets

[RISCV] Teach VSETVLInsert to eliminate redundant vsetvli for vmv.s.x and vfmv.s.f.

Differential Revision: https://reviews.llvm.org/D116307

Revert "[AArch64] Add a tablegen pattern for UZP2."

This reverts commit ada028c32f47ca84a0b7be5d1ab4e3c943f859a3.

A performance regression was reported that we need to investigate:

https://github.com/llvm/llvm-project/issues/52919

[IROutliner] Move global namespace cl::opt inside llvm::

[RISCV] Pre-commit test for Teach VSETVLInsert to eliminate redundant vsetvli for vmv.s.x and vfmv.s.f.

Differential Revision: https://reviews.llvm.org/D116306

[MC][test] Improve section_names.s

Add missing coverage like .tdata/.data1/.rodata1

[ELFAsmParser] Optimize hasPrefix with StringRef::consume_front

[ConstantFolding] Use ICmpInst::Predicate instead of plain integer

The function `ConstantFoldCompareInstruction` uses `unsigned short` to
represent compare predicate, although all usesrs of the respective
include file use definition of CmpInst also. This change replaces
predicate argument type in this function to `ICmpInst::Predicate`,
which allows to make code a bit clearer and simpler.

No functional changes.

Differential Revision: https://reviews.llvm.org/D116379

[cmake] Tweak warning in `extend_path` helper function

There was one more reference the word "install" I forgot to remove.

Follow-up to bde561c4813952847112600e5efe72d9015556f7 /
https://reviews.llvm.org/D115746

[compiler-rt][cmake] Factor out extend_install_path function

It is likely to become used again, if other projects want their own per-project
install directory variables. `install` is removed from the name since it is not inherently about installing.

Reviewed By: stephenneuendorffer

Differential Revision: https://reviews.llvm.org/D115746

[OpenMP] Add missing `tt_hidden_helper_task_encountered` along with `tt_found_proxy_tasks`

In most cases, hidden helper task behave similar as detached tasks. That means,
for example, if we have to wait for detached tasks, we have to do the same thing
for hidden helper tasks as well. This patch adds the missing condition for hidden
helper task accordingly along with detached task.

Reviewed By: AndreyChurbanov

Differential Revision: https://reviews.llvm.org/D107316

[RISCV] Use vmv.s.x instead of vfmv.s.f when the floating point scalar is 0.

Use integer vector scalar move instruction when move 0 to avoid add a integer-float move instruction.

Differential Revision: https://reviews.llvm.org/D116365

[NFC] Specify targets for clang stack-protector-guard.c

The run line of stack-protector-guard.c doesn't specify the triple,
which means it depends on the platform running the test. This makes
some failure hidden.

Reviewed By: nickdesaulniers

Differential Revision: https://reviews.llvm.org/D116003

[RISCV] Refactor immediate comparison instructions patterns

The patterns of the immediate comparison instruction is rewrite here, and put similar code to a class.
Do not change any function of the original code, making the code more concise.

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D116215

Couple of post-commit tweaks on 4d58d1d5af31 based on maskray's feedback

Fix build of llvm-prettyprinters/gdb/mlir-support.cpp test

This is just fixing the build itself, the test won't pass right now.

DWARFVerifier: fix remaining tests and compact/rephrase the output

DWARFDie: don't try to compute a full template name for a template parameter packs

Otherwise these look a lot like actual templates (they have a name and
they have template parameters) but they don't participate in naming
(this doesn't come up in practice because a template parameter pack DIE
is never referenced from another DIE (so we don't do full name
rebuilding for it) or the subject of simplified template name rebuilding
(never has the _STN prefix)) - it could be tested with some hand crafted
DWARF but doesn't seem important/useful to do so.

This change is just for performance - to avoid trying to parse more
DIEs, etc, when it's not needed when computing the name in the DWARF
verifier.

DWARFVerifier: Print the CU name and CU count to help visualize progress

[libc++] [NFC] Remove an unused parameter from `__sift_down`.

Differential Revision: https://reviews.llvm.org/D116382

DWARFVerifier: Delay loading nested types in type dumping to improve performance

Avoid trying to resolve nested types that may not be needed because the name is
already provided by the outer DIE.

[InstCombine] add more folds for unsigned overflow checks

 ((Op1 + C) & C) u<  Op1 --> Op1 != 0
 ((Op1 + C) & C) u>= Op1 --> Op1 == 0
 Op0 u>  ((Op0 + C) & C) --> Op0 != 0
 Op0 u<= ((Op0 + C) & C) --> Op0 == 0

https://alive2.llvm.org/ce/z/iUfXJN
https://alive2.llvm.org/ce/z/caAtjj

  define i1 @src(i8 %x, i8 %y) {
    ; the add/mask must be with a low-bit mask (0x01ff...)
    %y1 = add i8 %y, 1
    %pop = call i8 @llvm.ctpop.i8(i8 %y1)
    %ismask = icmp eq i8 %pop, 1
    call void @llvm.assume(i1 %ismask)

    %a = add i8 %x, %y
    %m = and i8 %a, %y
    %r = icmp ult i8 %m, %x
    ret i1 %r
  }

  define i1 @tgt(i8 %x, i8 %y) {
    %r = icmp ne i8 %x, 0
    ret i1 %r
  }

I suspect this can be generalized in some way, but this
is the pattern I'm seeing in a motivating test based on
issue #52851.

[InstCombine] add tests for unsigned overflow of bitmask offset; NFC

[InstCombine] add tests for lshr(add(shl())); NFC

[mlir][MemRef] Deprecate unspecified trailing offset, size, and strides semantics of `OffsetSizeAndStrideOpInterface`.

The semantics of the ops that implement the
`OffsetSizeAndStrideOpInterface` is that if the number of offsets,
sizes or strides are less than the rank of the source, then some
default values are filled along the trailing dimensions (0 for offset,
source dimension of sizes, and 1 for strides). This is confusing,
especially with rank-reducing semantics. Immediate issue here is that
the methods of `OffsetSizeAndStridesOpInterface` assumes that the
number of values is same as the source rank. This cause out-of-bounds
errors.

So simplifying the specification of `OffsetSizeAndStridesOpInterface`
to make it invalid to specify number of offsets/sizes/strides not
equal to the source rank.

Differential Revision: https://reviews.llvm.org/D115677

[Hexagon] Don't build two halves of HVX vector in parallel

There can only be one permute operations per packet, so this actually
pessimizes the code (due to the extra "or").

[Hexagon] Improve BUILD_VECTOR codegen

For vectors with repeating values, old codegen would rotate and insert
every duplicate element. This patch replaces that behavior with a splat
of the most common element, vinsert/vror only occur when needed.