Methinks that the choice of whether to relax or not should be decided outside of the assembler code. This directive sets the choice in stone and counters any choice done at build time, when optimizations are specified. For instance, when building a debug version, the optimizations may be different from when building a release version. This directive blocks such common practices and may create confusion and non expected results.

In D103004#2780185, @craig.topper wrote:

I'm also not sure why the rvv tests use no-aliases. I think the majority were generated by a tool developed before I get here. I'll ask around internally.

In D103004#2779570, @jrtc27 wrote:

So, can we just delete them all?

Rebase.

In D98002#2657389, @NickHung wrote:

Adding those "sched" information into base RVV instructions seems redundant? The scheduler works on PseudoRVV instructions.

Rebased.

In D99040#2645997, @craig.topper wrote:

Add multiclass for unsupported subextensions

This seems like a sensible level of granularity and reuse of existing resources.

Add the mask operand.

In D98002#2612677, @NickHung wrote:

I'm curious how instruction scheduling works if you don't add those resource models into the PseudoRVV instructions?

In D98002#2605618, @khchen wrote:

I'm curious about why there is no any load/store scheduling resources?

In D95049#2530687, @ebraminio wrote:

Thanks for the review :) So guess can be merged now?

Also, when the V spec becomes official, it'll be labeled v2.0. Therefore, as long as v0.9 or v1.0 is implemented, V is only available as an experimental feature.

Test is already in aliases.s.

If you happen to have a test case, please, consider adding it.

LGTM

LGTM

Address @HsiangKai's comments.

LGTM

RV32 tests are also needed, please.

LGTM, but, please, see if any of the lint notices can be addressed before committing.

The default should be ta and mu. The compiler is usually agnostic about the tail of the vector, but usually assumes that masked elements are preserved.

In D92228#2424007, @rogfer01 wrote:

One of the suggestions made in that thread is teaching RA new tricks, which I don't feel qualified to do :) (I envision that if RA were able to dynamically limit the valid registers, as it assigns registers to operands, by virtue of some target-specific constraints, then, perhaps, this would be doable. But tbh I have no idea such approach is even feasible in the current RA. If we could do that we could also solve the case where v0 can't be used as the destination of masked instructions).

The other suggestion is to amend the instructions after RA in a specific pass. Seems doable at first but I am afraid this is going to be testing hell just to make sure no instruction manages to escape from that pass incorrectly.

Supporting old names without change of function is sensible, but, in this case, the bit fields in satp are different from stpbr. Then, the sensible result should be an error, because the code does need to be ported to the new version of the spec.

This is a wider discussion, but I would favor following the ratified specs, with exceptions on specific cases. I would also favor that the toolchain would enforce compliance on its own, even if more currently than an official, yet non compliant, compliance test suite.

Note: this patch maintains backwards compatibility with a preliminary spec.

I agree with @jrtc27. What's the motivation to support a register name obsoleted by a ratified spec?

It LGTM, but it's better to wait a couple of days before committing in order to give others time to comment.

LGTM