LGTM

The function is done by D127576.

Rebase to origin/main and move the new test case into vsetvli-insert.ll.

Refine commit summary.

Address reames's comments.

Refine the comments.

Address Craig's comments.

LGTM.

Refine the commit message.

I am sorry that giving wrong comments made @sunshaoce rewrite and commit the code repeatedly. I promise I will review code more carefully and be more familiar with llvm.

I am sorry for creating the trouble. Should I revert the patch first?

LGTM. It's fine to me that not declare isFaultFirstLoad as a static function of class RISCVInstrInfo, although I prefer this method.

Thank you for providing your cmake command.

I am sorry to create the trouble, but I didn't encounter this problem in my local. Could you provide me your cmake command?
My cmake command:

cmake -G "Ninja" -DLLVM_ENABLE_PROJECTS="clang" -DLLVM_BUILD_EXAMPLES=False -DLLVM_PARALLEL_LINK_JOBS=2 -DCMAKE_BUILD_TYPE=Debug ../llvm

Remove useless definition of TSFlags.

Add comments for RISCVInsertVSETVLI and uses MI.getNumExplicitDefs() == 2 && MI.modifiesRegister(RISCV::VL) && !MI.isInlineAsm() to identify VLEFF/VLSEGFF instead of adding new TSFlag.

Address reames's comment to use exactly one set pseudo of VLEFF/VLSEGFF. Thank that reames's comments make the patch cleaner.

Simplify code about expanding VLEFF/VLSEGFF.

Remove test cases of "[RISCV] Make PseudoReadVL have the vtypes of the corresponding VLEFF/VLSEGFF."

LGTM.

In D123581#3532019, @reames wrote:

I am generally not a fan of this patch. The entire PsuedoReadVL mechanism feels like a hack, and the unchecked assumption that the SEW and policy bits on the ReadVL match the prior VLE is worrying. Beyond that, this adds a decent amount of complexity.

I find myself agreeing with @craig.topper's comment above. It really feels like we need a pseudo instruction for VLEnFF itself here. Such a psuedo would produce two outputs, the second being the GPR version of VL. After this pass, we could lower the pseudo into two instructions (e.g. the actual VLEnFF and the CSR read). This would make the state update on this patch very minimal. This really feels to me like the "right" approach here.

In D126273#3533580, @liaolucy wrote:

When I test tsvc.

The IR is:

@llvm.fmuladd.nxv2f32(<vscale x 2 x float>.....

Not

@llvm.riscv.vfmul.nxv2f32.nxv2f32(<vscale x 2 x float> ......
@llvm.riscv.vfadd.nxv2f32.nxv2f32(<vscale x 2 x float> ......

So I am not sure, we need merge vp.fmul and vp.fadd to vp.fma. maybe vp.fma is enough?

Rename fold-fadd-and-fmul.ll to fold-vp-fadd-and-vp-fmul.ll.

Using clang-format.

After fixing getNode, pass SDNodeFlags to getNode of SDVTList version.

Add REQUIRES: asserts in pass-fast-math-flags-sdnode.ll.

The update removes the part of vp.fcmp support and using argument of DAG.getNode to pass flags.

Rename class form [SelectionDAGBuilder] to [VP].

Directly use PseudoReadVL to get VSETVLIInfo also change the commit name and summary.
Additionally, the update removes useless PseudoReadVL in the pass.

Refine the comments of createMIROperandComment.

Add human readable comment for vtypes of PseudoReadVL MIs.

Should I create a new revision for changing PseudoReadVL? Or I just do the change in the revision and also update the commit name and summary?

In D123581#3482841, @craig.topper wrote:

Would adding SEW and LMUL from the VLEFF to the PseudoReadVL that gets emitted for VLEFF help without requiring us to give the VLEFF the GPR output?

I think it is a better solution, we could just check vtype of PseudoReadVL for PseudoReadVL's user and we even don't need the new status VLModified.

In D123581#3445896, @craig.topper wrote:

Would it simplify things if the VLEFF pseudo instruction had the GPR output and the vector register output. And we expanded it PseudoReadVL after register allocation?

The update replaces specefic function only calling combineBinOpToReduce with combineBinOpToReduce and uses array input version setTargetDAGCombine.

Since we need to transform VECREDUCE to VP_REDUCE before legalization for Fraser's method, we need to deal with illegal type of VECREDUCE. If we don't have idea to deal with illegal type nodes of VECREDUCE, how about we just use my original combine?

In D122563#3438080, @craig.topper wrote:

-Do we currently mark VP_REDUCE nodes as Expand on targets that don't support it? I don't see anything in TargetLoweringBase::initActions, but maybe I missed it. I think we would need that fixed to know if we could do the combine so that we only do it on targets that support it.

VP_REDUCE nodes are marked as Custom. VP_REDUCE opcodes are elements of IntegerVPOps and FloatingPointVPOps whose elements would be marked as Custom.

In D123581#3445896, @craig.topper wrote:

Would it simplify things if the VLEFF pseudo instruction had the GPR output and the vector register output. And we expanded it PseudoReadVL after register allocation?

Fix the issue raised by reviewers.