Identified by misc-unused-using-decls.

This is in advance of a following change which needs to the non-icmp API.

VPWidenCanonicalIVRecipe does not create PHI instructions, so it does
not need to be placed in the phi section of a VPBasicBlock.

Also tidies the code so the WidenCanonicalIV recipe and the
compare/lane-masks are created in the header.

Discussed D113223.

Reviewed By: Ayal

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

hasInterestingContent was introduced without a use on Sep 15, 2015 in
commit e5162dba.

The last use was removed on May 31, 2016 in commit
f9acacaa.

These functions seem to be unused for at least 1 year.

For .vf instructions, we don't need MF8 pseudos for f16. We don't
need MF8 or MF4 pseudos for f32. Or MF8, MF4, MF2 for f64.

Reviewed By: khchen

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

Identified with readability-redundant-member-init.

Identified by readability-redundant-string-init.

This adds at extra check into ARMBaseInstrInfo::verifyInstruction to
verify the offsets used in addressing mode immediates using
isLegalAddressImm. Some tests needed fixing up as a result, adjusting
the opcode created from CMSE stack adjustments.

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

Changed by https://reviews.llvm.org/D65455

It’s still possible to build parts of the main llvm build (lld, clang etc) by symlinking them into llvm/tools.

Reviewed By: Ericson2314

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

The function is declared in AArch64.h.

Identified with readability-redundant-declaration.

This was suggested as a separate cleanup in recent reviews.

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

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

The IR verifier should probably catch this. Alive2 did, though.

InitializePasses.h contains the proper declaration.

Identified with readability-redundant-declaration.

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

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

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

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

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

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