LGTM

Upload complete diff

There is an option to scale the LMUL returned to the vectorizer by TTI getRegisterBitWidth. Using that you can get LMUL>1 fixed vector loops. https://godbolt.org/z/34asbPcv7 should work for scalar too.

clang-format

Rename variable. Cleanup comment slightly.

In D125747#3541849, @Miss_Grape wrote:

In D125747#3518172, @craig.topper wrote:

Do you have any performance data?

I use the TSCV test suit, then run on the spike,

when option: -scalable-vectorization=on, the performance more better. But I'm not sure if the performance data from the spike run can be used as a standard to measure performance

LGTM

What is it isn't known to be null at compile time but gets optimized to it. Are we trying to make passing a null pointer defined behavior for these intrinsics?

In D113291#3539965, @efriedma wrote:

as for the second I'm not sure when it would be profitable to transform back and emit the table

You really just have to weigh it against the current default expansion on targets where ctlz/cttz aren't legal, which is popcount(v & -v). It should be a straightforward comparison, generally. If you have popcount, use it. If multiply is legal, use a table lookup. Otherwise... maybe stick with the popcount expansion? Probably any approach is expensive at that point.

In D113291#3540303, @dmgreen wrote:

In D113291#3539965, @efriedma wrote:

as for the second I'm not sure when it would be profitable to transform back and emit the table

You really just have to weigh it against the current default expansion on targets where ctlz/cttz aren't legal, which is popcount(v & -v). It should be a straightforward comparison, generally. If you have popcount, use it. If multiply is legal, use a table lookup. Otherwise... maybe stick with the popcount expansion? Probably any approach is expensive at that point.

Compare the generated code for arm-eabi.

You may not want to do that for non-hot ctzs?

As opposed to what, calling into compiler-rt?

I was meaning - it can be difficult for the compiler to recognize _when_ a ctz is performance critical. If the size of the table is large (which I was possible over-estimating the size of in my mind), then you may not want to emit the table for every ctz in the program. Currently that places where this is used have said, from the fact that they wrote it this way, that these ctz's are important. It just depends on whether converting to a table is always better, and if the table it small enough to be reasonable in the common case. 32 x i8 doesn't sound too big compared to what I originally imagined, if that is all it needs.

Ping

In D126465#3540599, @reames wrote:

I'm a bit confused by this patch. Where does the VLEN > 32 bit come from? All I kind find in the spec is that VLEN >= ELEN, and must be a power of 2. Given ELEN only has to be 8, shouldn't the smallest VLEN also be 8? This seems like an utterly useless configuration, but the spec seems to allow it?

I don't understand the motivation for this change. LLVM coding guidelines encourage using early returns.

Use DestReg as the source for the second operation.

Instead of dividing in half use a large immediate, either -2048 or (2048-stackalign),
to do a first adjustment. Then a smaller adjustment for the remainder.

In D126392#3537748, @jrtc27 wrote:

Doesn't this run the risk of temporarily misaligning the stack (e.g. for Val == 2064)? The psABI says using such a non-standard ABI within a function is fine and that kernels should realign stacks before calling signal handlers. Both FreeBSD and Linux correctly do this for signal handlers so as to not make assumptions about whether userspace is following the standard ABI, but both assume that the kernel itself is following the standard ABI, and so do not realign the stack in their exception entry points, causing the stack to be misaligned if an interrupt is taken in between. Whether this is a bug or not in the kernels is debatable, but with a more careful splitting of Val it should be possible to avoid anyway, with the exception of 4080?

LGTM

LGTM

LGTM

Is it possible to test this?

LGTM

Rebase. I used the wrong repo so it might have been older than I meant it to be.

LGTM

The use of vscale came from the scalable vector autovectorizer. llvm.vscale is VLEN/RISCV::RVVBitsPerBlock. Which I guess is the right VLMAX for SEW=RISCV::RVVBitsPerBlock where RISCV::RVVBitPerBlock is 64.

Add a method to convert opcode to operand kind. All opcodes listed with an
unreachable default to make sure it always gets updated if new opcodes are used.

LGTM. Other than that last comment.

In D126317#3535274, @reames wrote:

I want to suggest an alternate, and possibly simpler change.

Instead of adding a field to Inst, what if we added a helper routine instead which just did the switch on opcode internally and returned the Kind? The client code would look largely the same, but without needing to explicitly track the kind of each opcode at the construction site.

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?

LGTM