In D108886#2978169, @apivovarov wrote:

Add Cortex-A78C Support for Clang and LLVM is similar to this patch. As we can see cortex-a78c support was included to the ReleaseNotes 12.x. From the other side adding sifive-e76 and sifive-u74 support has not been mentioned in the Release Notes for version 12.0

In D108886#2978038, @apivovarov wrote:

Evandro, similar notes have been made in the past for Release Notes 12.x and 11.x for Arm and RISC-V processors:
https://github.com/llvm/llvm-project/blob/release/12.x/clang/docs/ReleaseNotes.rst#modified-compiler-flags
https://github.com/llvm/llvm-project/blob/release/11.x/clang/docs/ReleaseNotes.rst#modified-compiler-flags

I don't think that such a minor change makes sense to be added to the release notes.

LGTM

In D109037#2975976, @jrtc27 wrote:

The change makes sense, surprised this wasn't already the case. Have you done any kind of extensive testing to try and verify there aren't things we're missing that would break shrink wrapping (beyond the bug that motivated the original test case)? That'd really be my only concern.

Add the scheduling resources for the V extension loads and stores.

In D102535#2819032, @luismarques wrote:

I thought I understood your point initially, but now I'm not sure. Can you clarify what flexibility you're losing? Doesn't the emission of this directive reflect exactly the build settings you specify at compilation time? Why is it important to override this later?

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.