Page MenuHomePhabricator

[RISCV] Lower experimental_get_vector_length intrinsic to vsetvli for some cases.
Needs ReviewPublic

Authored by craig.topper on Wed, May 17, 3:42 PM.



This patch lowers to vsetvli when the AVL is i32 or XLenVT and
the VF is a power of 2 in the range [1, 64]. VLEN=32 is not supported
as we don't have a valid type mapping for that. VF=1 is not supported
with Zve32* only.

The element width is used to set the SEW for the vsetvli if possible.
Otherwise we use SEW=8.

Diff Detail

Event Timeline

craig.topper created this revision.Wed, May 17, 3:42 PM
Herald added a project: Restricted Project. · View Herald TranscriptWed, May 17, 3:42 PM
craig.topper requested review of this revision.Wed, May 17, 3:42 PM
Herald added a project: Restricted Project. · View Herald TranscriptWed, May 17, 3:42 PM
asb added a comment.Fri, May 19, 7:15 AM

I think you meant to mark this as dependent on D149916.

Rebase on parent patch

reames added inline comments.Thu, May 25, 12:31 PM

For fixed vectors, we should be able to statically compute this when the ElementWidth * VF is less than VLEN right? It's fine to do that in a different patch, just want to make sure I'm not missing something.


Why not i16? I don't see anything in the implementation which couldn't be handled via an extend?


The "if possible" bit is bugging me here. Isn't this a hard requirement? VLMAX should be a function of SEW and LMUL. Given the result here depends on VLMAX, don't we have a hard requirement on having a recognized SEW/LMUL combination?



craig.topper added inline comments.Thu, May 25, 12:53 PM

The ElementWidth doesn't have any real meaning. The vectorizer already picked a VF. The get_vector_length is asking, given that VF, how many elements fit in that type. The width of the elements or VLEN doesn't change that answer.

I guess we could return a lower number but that means we'd never use the entire type the vectorizer is emitting. That seems like we a cost model issue if we actually want to use less than the type the vectorizer picks.


No strong reason. Might need to add setOperationAction(ISD::INTRINSIC_WO_CHAIN, MVT::i16, Custom) to get the legalization to be called.

reames added inline comments.Thu, May 25, 1:21 PM

I see your point for fixed length vectors. Essentially, we can let the vectorizer pick one via cost modeling, and then split as needed. So here, we can report the number of elements even if splitting might be required.

Rebase after removing element width from the intrinsic.