Page MenuHomePhabricator

[CodeGen][SVE] CopyToReg: Split scalable EVTs that are not powers of 2

Authored by sdesmalen on May 18 2020, 9:30 AM.



Scalable vectors cannot use 'BUILD_VECTOR', so it is necessary to
properly split and widen scalable vectors when passing them
to CopyToReg/CopyFromReg.

This functionality is added to TargetLoweringBase::getVectorTypeBreakdown().

This patch only adds support for 'splitting' scalable vectors that
are a multiple of some legal type, e.g.

<vscale x 6 x i64> -> 3 x <vscale x 2 x i64>

Diff Detail

Event Timeline

sdesmalen created this revision.May 18 2020, 9:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 18 2020, 9:30 AM
sdesmalen marked 2 inline comments as done.May 18 2020, 9:38 AM
sdesmalen added inline comments.

The reason for not implementing this yet is because I don't have a way to test it.


note: Widening of scalable vectors requires a bit more thought.

For example, I wasn't sure how a <vscale x 3 x i8> should be widened at this level. Is it widened to a <vscale x 4 x i8> and then promoted to a <vscale x 4 x i32>, or do we keep it simple and always insert it into an UNDEF of the first legal type (<vscale x 16 x i8> for SVE).

It would also require changes to legalise e.g. <vscale x 9 x i16>, that needs both widening to <vscale x 16 x i16>, and then splitting to two <vscale x 8 x i16>.

The case handled by this patch allows it to support the tuple types for the structured load/store instructions, such as svint32x3_t (implemented as <vscale x 12 x i32>).

efriedma added inline comments.May 18 2020, 3:48 PM

I think the only way to trigger this is by adding more types to llvm/include/llvm/Support/MachineValueType.h; it's fine to ignore that for now.


For widening values that fit in a single register, I think we should do whatever getTypeToTransformTo() would do. If you look a few lines up, there's a call to getTypeAction(); that code is supposed to handle cases where the type would fit into a single vector register. It probably makes sense to enhance it to be a bit more comprehensive in cases where there's more than one legalization step involved.

If we have a value with a legal element type that has more elements than the legal vector type, I guess we have to widen, then split: so <vscale x 9 x i16> would end up using <vscale x 8 x i16> components.


Is flooring division correct here?

c-rhodes added inline comments.May 19 2020, 5:43 AM

do you mean <vscale x 16 x i8> %legal? (and below)

sdesmalen updated this revision to Diff 266560.May 27 2020, 8:50 AM
  • Reuse getTypeConversion to break down the vector into legal parts.
  • Added an assert that the illegal vector can be broken into some integer multiple of part-vectors.
  • Fixed up <vscale x 14 x .. types in tests.
efriedma added inline comments.May 27 2020, 4:14 PM

I'm pretty sure this assert doesn't hold in general. If you don't want to think about it right now, I guess you can leave a FIXME.

sdesmalen updated this revision to Diff 266781.May 28 2020, 2:25 AM

Added FIXME describing limitations of vector type breakdown.

This revision is now accepted and ready to land.May 28 2020, 1:33 PM
This revision was automatically updated to reflect the committed changes.