This is leftover from the advisor refactoring. Straight-forward copy and
paste.

The first phase of the analysis can avoid a vsetvli if an earlier
instruction in the block used an SEW and LMUL that when combined with
the EEW of the load/store would produce the desired EMUL. If we
avoided a vsetvli this will affect the global analysis we do in the
second phase.

The third phase where we really insert the vsetvlis needs to agree
with the first phase. If it doesn't we can insert vsetvlis that
invalidate the global analysis.

In the test case there is a VSETVLI in the preheader that sets
SEW=64 and LMUL=1. Inside the loop there is a VADD with SEW=64 and LMUL=1.
This VADD is followed by a store that wants wants SEW=32 LMUL=1/2.
Because it has EEW=32 as part of the opcode the SEW=64 LMUL=1 from the
VADD can be become EMUL=1 for the store. So the first phase determines no
vsetvli is needed.

The third phase manages CurInfo differently than BBInfo.Change from the
first phase. CurInfo is only updated when we see a vsetvli or insert
a vsetvli. This was done to allow predecessor block information from
the global analysis to be applied to multiple instructions. Since the
loop body has no vsetvli we won't update CurInfo for either the VADD
or the VSE. This prevented us from checking the store vsetvli elision
for the VSE resulting in a vsetvli SEW=32 LMUL=1/2 being emitted which
invalidated the global analysis.

To mitigate this, I've added a BBLocalInfo variable that more closely
matches the first phase propagation. This gets updated based on the
VADD and prevents emitting a vsetvli for the store like we did in the
first phase.

I wonder if we should do an earlier phase to handle the load/store case
by adding more pseudo opcodes and changing the SEW/LMUL for those
instructions before the insertion analysis. That might be more robust
than trying to guarantee two phases make the same decision.

Fixes the test from D118629.

Reviewed By: frasercrmck

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

Make specializations of `DataflowAnalysis` extendable with domain-specific
logic for comparing distinct values when comparing environments.

This includes a breaking change to the `runDataflowAnalysis` interface
as the return type is now `llvm::Expected<...>`.

This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.

Reviewed-by: ymandel, xazax.hun

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

This should not be an error. V is a valid implementation of Zve.

Spec clarified here
https://github.com/riscv/riscv-v-spec/commit/9a877e8553362ff03a9b22b98e321b59aff50398

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

In a similar vein to 236fbf57,
make sure we don't early-exit before the dead constant check.

This seems to be the root cause of hangs on amdgpu. Reverting while investigating.
This reverts commit 7b9844cc.

Summary:
This patch removes some of the check lines that are problematic on
MACOS. The output on the MAC systems works but should be slightly
different. Because this is simply the output being slightly different
rather than broken functionality the test is being changed.

Constant expressions with a non-pointer result type used an early
exit that bypassed the later dead constant user check, and resulted
in different optimization outcomes depending on whether dead users
were present or not.

This fixes the issue reported in https://reviews.llvm.org/D117223#3287039.

[PowerPC] Update P10 vector insert patterns to use refactored load/stores, and update handling of v4f32 vector insert.

This patch updates the P10 patterns with a load feeding into an insertelt to
utilize the refactored load and store infrastructure, as well as updating any
tests that exhibit any codegen changes.

Furthermore, custom legalization is added for v4f32 on Power9 and above to not
only assist with adjusting the refactored load/stores for P10 vector insert,
but also it enables the utilization of direct moves.

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

This patch adds the ability to lower an empty subroutine.

Reviewed By: kiranchandramohan

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

Pointer element types do not imply that the pointer is ABI aligned.
We should be using either an explicit align attribute here, or fall
back to an alignment of 1. This fixes a new element type access
introduced in D117764.

I don't think this makes any practical difference though, as the
lowering does not depend on alignment.

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

Auto-generated patch based on clang-tidy readability-identifier-naming.
Only some manual cleanup for `extern "C"` declarations and a GTest change was required.

I'm not sure if this cleanup is actually very useful. It cleans up clang-tidy findings to the number of warnings from clang-tidy should be lower.  Since it was easy to do and required only little cleanup I thought I'd upload it for discussion.

One pattern that keeps recurring: Test **matchers** are also supposed to start with a lowercase letter as per LLVM convention. However GTest naming convention for matchers start with upper case. I would propose to keep stay consistent with the GTest convention there. However that would imply a lot of `//NOLINT` throughout these files.

To re-product this patch run:
```
run-clang-tidy -checks="-*,readability-identifier-naming" -fix -format ./clang-tools-extra/clangd
```

To convert the macro names, I was using this script with some manual cleanup afterwards:
https://gist.github.com/ChristianKuehnel/a01cc4362b07c58281554ab46235a077

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

While prepending lines to the copied source files is functional, it
disturbs the line numbering between the original and the copy.  That
makes development more awkward than necessary, as it is the copy that
generally gets compiled first and emits compiler errors.

This uses sed to alter the first two lines, and also emits better
emacs mode setting, getting both C++ mode and read-only mode.

While here, also update and clarify documentation.

Reviewed By: ChuanqiXu

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

This way we have at most 1 allocation even if the number of includes is greater than the on-stack size of the small vector.

This way we have at most 1 allocation even if the number of includes is greater than the on-stack size of the small vector.

* Avoid repeatedly calling std::string::append(char) in a loop.
* Reserve before calling std::string::append(const char *) in a loop.

The test introduced in https://reviews.llvm.org/D118006 was missing a return and would
introduce a non-0 return which would fail tests.

This patch puts in place the differents
function to lower the evaluation list. All functions
are just placholders with TODOs for now.
Follow up patches will bring the proper lowering in these
functions.

Reviewed By: jeanPerier

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

Simplifies an upcoming change.

Somehow the test introduced in https://reviews.llvm.org/D118006 produces the expected result but running
through lli with Intel SDE activated sneaks in an error code 2 (before this commit) or an error code 10
(after this commit).

The test as is is still meaningful in that the LLVMIR generation would crash if the `elementtype` is set
improperly.

Still, this should run with lli turned on.

As raised on rGffd0e464, if x is poison, this fold is still ok.

Inspired by a recent Discourse post on undef vs. poison usage, this
series of patches should reduce the number of undefs in LLVM tests by
around 10%.

Only undef vector operands to insertelement/shufflevector have been
handled, which are by far the most common we've got.

The switchover is split into 3 fairly arbitrary clusters to make it
slightly more manageable: vector predication, fixed-length vectors,
scalable vectors.

It doesn't like implicit `this` in generic lambdas.

This revision adds enough support to allow InlineAsmOp to work properly with indirect memory constraints "*m".
These require an explicit "elementtype" TypeAttr on the operands to pass LLVM verification and need to be provided.

Reviewed By: bkramer

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