This is an archive of the discontinued LLVM Phabricator instance.

[RISCV] Add initial support for 128-bit fixed vectors with RVV.
AbandonedPublic

Authored by craig.topper on Jan 27 2021, 2:25 PM.

Details

Summary

This adds basic support for 128-bit fixed vectors using a single vector
register as the 1.0 V spec has a minimum VLEN of 128 bits. This
first patch includes support for VV versions of the integer and FP
binary operations and vector loads and stores. This is all off by
default and requires a command line to enable.

Portions of this are inspired by the D91638 proof of concept from
Fraser Cormack.

Diff Detail

Event Timeline

craig.topper created this revision.Jan 27 2021, 2:25 PM
craig.topper requested review of this revision.Jan 27 2021, 2:25 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 27 2021, 2:25 PM
Herald added a subscriber: MaskRay. · View Herald Transcript

Drop some things that aren't needed yet.

Add rv32 command lines

Support fneg based on D95568

HsiangKai added a comment.EditedJan 27 2021, 3:14 PM

LGTM. Wait for Fraser Cormack's review.

khchen added a subscriber: khchen.Jan 27 2021, 7:41 PM

LGTM in general. I've been wondering if/how we're going to interact with the proposed P extension. Because that will presumably be adding patterns for v2i16, v4i8, etc. Do we need an additional Tablegen predicate to control our fixed-len V patterns?

LGTM in general. I've been wondering if/how we're going to interact with the proposed P extension. Because that will presumably be adding patterns for v2i16, v4i8, etc. Do we need an additional Tablegen predicate to control our fixed-len V patterns?

Maybe. Is it likely that both would be used at the same time? And if they are which one should have priority?

Maybe. Is it likely that both would be used at the same time? And if they are which one should have priority?

That's what I've been wondering. If it's a possibility we should handle it somewhat gracefully. But I struggle to see us selectively handling certain types with V and others with P, so I reckon we'd just make a top-level all-or-nothing choice, possibly based on a user option. I guess I intuitively think P takes priority since it's specialised for those types?

This isn't something I've solved for myself, but it was making me hesitant to update my fixed-length patches.

Maybe. Is it likely that both would be used at the same time? And if they are which one should have priority?

That's what I've been wondering. If it's a possibility we should handle it somewhat gracefully. But I struggle to see us selectively handling certain types with V and others with P, so I reckon we'd just make a top-level all-or-nothing choice, possibly based on a user option. I guess I intuitively think P takes priority since it's specialised for those types?

This isn't something I've solved for myself, but it was making me hesitant to update my fixed-length patches.

At least in the td file patterns we shouldn’t have a problem with types overlapping if we use 128 bit for fixed vectors with V. I think we may eventually end up needing to lower fixed vectors to a user controlled vector width. Which likely means we’ll eventually need to lower fixed vectors to scalable vectors with a VL argument earlier than isel patterns. I think AArch64 has some support for something similar.

Had you consider SVE's minimum vector length approach?
https://reviews.llvm.org/D80385
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/AArch64/AArch64Subtarget.cpp#L50-L54
maybe giving the variable minimum vector length is more flexible?

Matt added a subscriber: Matt.Jan 28 2021, 8:32 AM
craig.topper abandoned this revision.Feb 10 2021, 1:36 PM

Abandoning in favor of D95705