Reverting because mis-compiles:
- https://github.com/llvm/llvm-project/pull/131837
- https://github.com/llvm/llvm-project/pull/146320
- https://github.com/llvm/llvm-project/pull/146337

the extension enabled with xmipscbop.

Please refer "MIPS RV64 P8700/P8700-F Multiprocessing System
Programmer’s Guide" for more info on the extension at
https://mips.com/wp-content/uploads/2025/06/P8700_Programmers_Reference_Manual_Rev1.84_5-31-2025.pdf

Similar to #139872. This patch adds isel patterns to match
`riscv_brcc` and `riscv_selectcc_frag` to XAndesPerf branch
instructions.

Inspired by s2101 in tsvc

When generating SDAG for a getelementptr with a vector result, we were
previously generating splats for each scalar operand. This essentially
has the effect of aggressively vectorizing the sequence, and leaving it
later combines to scalarize if profitable.

Instead, we can keep the accumulating address as a scalar for as long as
the prefix of operands allows before lazily converting to vector on the
first vector operand. This both better fits hardware which frequently
has a scalar base on the scatter/gather instructions, and reduces the
addressing cost even when not as otherwise we end up with a scalar to
vector domain crossing for each scalar operand.

Note that constant splat offsets are treated as scalar for the above,
and only variable offsets can force a conversion to vector.

---------

Co-authored-by: Craig Topper <craig.topper@sifive.com>

Similarly to #146710, for vslide1ups vl only determines the destination
elements written to so we can safely reduce their AVL.

We cannot do this for vslide1downs as the vl determines which lane the
new element is to be inserted in, so some negative tests have been
added.

For vslideup and vslidedown, vl controls the elements which are written
just like other vector instructions. So unless I'm missing something it
should be safe to reduce them. For vslidedown, the specification states
that elements past vl may be read.

We already reduce vslideup and vslidedown in
RISCVVectorPeephole::tryToReduceVL where we just check for
RISCVII::elementsDependOnVL.

Eventually we should replace the whitelist with
RISCVII::elementsDependOnVL once we have test coverage. I've also added
an assert just to double check the instructions we currently support.

This helps reduce vl toggles for fixed-order recurrences vectorized with
EVL tail folding.

I noticed these were missing when seeing some extra vl toggles with EVL
tail folding.

This helps remove quite a few vsetvlis in llvm-test-suite

This is alternative to #145965 that allows RegisterSDNode to be handled
without making a special case.

Always try to fold freeze(op(....)) -> op(freeze(),freeze(),freeze(),...).

This patch proposes we drop the opt-in limit for opcodes that are allowed to push a freeze through the op to freeze all its operands, through the tree towards the roots.

I'm struggling to find a strong reason for this limit apart from the DAG freeze handling being immature for so long - as we've improved coverage in canCreateUndefOrPoison/isGuaranteedNotToBeUndefOrPoison it looks like the regressions are not as severe.

Hopefully this will help some of the regression issues in #143102 etc.