In D32530#1470784, @hfinkel wrote:

In D32530#1470773, @greened wrote:

We need to clarify on insertelement/extractelement. Maybe already done in some other patches, but that clarification should be part of this patch.
Is the "length of val" under the semantics "scalable * n" in <scalable n x ElemTy>, right? Or is it still n?

I am not sure how it could be anything but n. If you don't know how long the vector is, you can't correctly generate an index beyond n.

But you know at runtime... there has to be a way to determine, at runtime, vscale. And the index doesn't need to be a constant. I'm not sure that we need to restrict non-constant n to only values valid for vscale == 1.

In D32530#1470773, @greened wrote:

We need to clarify on insertelement/extractelement. Maybe already done in some other patches, but that clarification should be part of this patch.
Is the "length of val" under the semantics "scalable * n" in <scalable n x ElemTy>, right? Or is it still n?

I am not sure how it could be anything but n. If you don't know how long the vector is, you can't correctly generate an index beyond n. I assume for vectors of length > n one would have to use shufflevector or something similar (using vscale and stepvector as Graham mentioned) to get the elements you want to the lower n positions.

Either way, the semantics and any restrictions certainly need to be documented.

In D32530#1468145, @simoll wrote:

That's pretty much what LLVM-VP is about: https://reviews.llvm.org/D57504

We are proposing compress/expand and lane shift as intrinsics.
I suggest you add any shuffle intrinsics to the same namespace to avoid fragmentation.

In D32530#1464722, @hsaito wrote:

In D32530#1463735, @joelkevinjones wrote:

I think this is a coherent set of changes. Given the current top of trunk, this expands support from just assembly/disassembly of machine instructions to include LLVM IR, right? Such being the case, I think this patch should go in. I have some ideas on how to structure passes so SV IR supporting optimizations can be added incrementally. If anyone thinks such a proposal would help, let me know.

I think there is one more thing we still have to do. Does scalable vector type apply to all Instructions where non-scalable vector is allowed? If the answer is no, we need to identify which ones are not allowed to take scalable vector type operand/result. Some of the Instructions are not plain element-wise operation. Do we have agreed upon semantics for all those that are allowed?

• Clarified that the runtime multiple is constant across all scalable vector types, even if the constant value isn't known at compile time.
• Removed extra whitespace.

I think this patch is a good start and I don't mind having it merged as is, I was just suggesting a way forward since it seems people are still hesitating. While there seems to be some consensus on moving forward with native types, I'm sure many of the details are still somewhat fuzzy. In my opinion having more patches reviewed would make those details clear, and it would thus make it easier to get more sign-offs on this patch as well.

I'd advise caution here, it's really significant/impactful change, and a single sign-off is a bit worrying.
In particular, even regardless of the feature itself, has the implementation itself been reviewed?

In D32530#1448135, @sebpop wrote:

I am accepting the scalable vector types based on the comments in
http://lists.llvm.org/pipermail/llvm-dev/2019-March/131137.html

Let's move forward with SVE support in LLVM. Thanks!

In D31417#1450587, @xtian wrote:

LGTM. This provides a consistent behavior same as GCC and ICC w/ -fopenmp-simd option. To answer, Kelvin's question. it is not directly tied with "target".

A more focused set of unit tests will be created instead of this demonstration test.

A better set of patterns will be created later.

A better set of patterns will be created later.

A better set of patterns will be created later.

Needs to be updated with better isel patterns (and possibly a new ISD?), instead of just the bare minimum required for demonstration.

Needs to be updated with better isel patterns, instead of just the bare minimum required for demonstration.

Needs to be updated with better isel patterns, instead of just the bare minimum required for demonstration.

Rebased, incorporated fixes from reviews.

Update based on off-list feedback:

• Added a section on allowed operations to clarify this is a first class type.
• Remove initial proposal on the flag for not inheriting vlen; there's more pushback against allowing runtime multiple changes. I think this design could still be extended to support that in the future, but I'm afraid I'll have to leave that battle to the RVV team.
• Minor wording changes.

• Unified ScalableSize representation
• Changed to uint64_t + boolean, since we no longer allow scalable vectors in aggregates
• Removed aggregate and mixed unit tests

• Added checks in verifier to prevent scalable vectors being included in structs or arrays
• Changed lookup to use ElementCount
• Moved ElementCount to a new file
• More unit tests

Updated based on feedback:

• Add reasons for restrictions on global/aggregates
• Change size query struct to an integer + a boolean instead of two integers.

In D53695#1277187, @rengolin wrote:

Also, can you move this to docs/Proposals, together with the other RFCs, please?

Updated based on discussions at the 2018 devmeeting

Abandoning this. At the devmeeting it was agreed that 'getPrimitiveSizeInBits' should continue to work as-is for fixed-length vectors and only behave differently for scalable vectors.

Indeed, we shouldn't allow scalable vectors to be globals. I've added a check for that in the verifier, plus unit tests and a small update to the langref. Thanks.

I think the discussion on the mailing list has reached agreement on this type being suitable for both SVE and RVV; any review comments on the code or tests?

Fixed string representation of scalable vectors which don't map to the existing defined set of MVTs.

Removed unnecessary metadata.

Updated RFC including a list of patches for simple codegen using this extension has been posted: http://lists.llvm.org/pipermail/llvm-dev/2018-June/123780.html

I have also changed vscale and stepvector to be intrinsics, but as that makes those patches just an addition to Intrinsics.td I won't post them yet.

Changed textual IR format to match Chris's suggestion from the mailing list.

In D31417#886441, @hfinkel wrote:

Is this still being worked on?

New RFC posted to llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2017-June/113587.html

Improved constructor based on Renato's suggestion. Thanks.

Added unit tests via gtest framework.
Changed getHalfNumVectorElementsVT to use 'EltCnt.Min' when determining whether the current vector length is evenly divisible.
Changed iterator names to be more obvious.

In D32019#730341, @rengolin wrote:

Right, the code looks good now, but I'm worried about tests... We don't seem to have unit tests on this area and I'm not sure how we'd create one (not terribly familiar here).

We could wait to have IR tests, like the rest, when AArch64 uses it... If everyone agrees with it.

In D32017#730310, @rengolin wrote:

Looks good to me to, but, what about tests?

Changed 'Min' to unsigned.
Moved text to asserts instead of comments.
Added FIXME to explain why extended scalable vector types aren't handled yet.

Changed SimpleValueType enum back to 8 bits, but made it unsigned. Renumbered all of them, with 0 now being the invalid value.

Removed unused functions, moved assert on halving the number of elements when there's an odd element count.