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.

See http://lists.llvm.org/pipermail/llvm-dev/2017-March/110772.html for earlier discussion on these types.

Changed to transform combined constructs to simd in ParseOpenMP.cpp instead of creating a new pragma handler. This also made it easier to add support for 'declare simd': only needed the addition of a check for the option when code generating functions to enable it, so I've added a RUN line to test it in the 'declare simd' codegen tests.

Hi Renato,

In D31417#712008, @fpetrogalli wrote:

Hi Graham,

thank you for working on this. I understand that you are gonna take care of the CodeGen side of things for the new -fopenmp-simd option in a separate patch?

In D29219#667645, @rengolin wrote:

In D29219#667592, @huntergr wrote:

Ping.

Hi Graham,

I was waiting from other comments, especially regarding the tied operand logic for other targets, which I'm not familiar with. I'm surprised this didn't trigger anything else in any other target. Are you building and testing all targets?

For clarity wrt. the movk/bic/orr pattern changes, they never triggered when printing asm before because the base patterns in AArch64InstrFormats.td (BaseInsertImmediate and BaseSIMDModifiedImmVectorTied) both contain tied register constraints. Since they now print with this change, I've adjusted the priority where needed to avoid breaking the existing unit tests, and just change ins to mov.

In D29219#658698, @rengolin wrote:

Hi Graham,

This looks ok to me, but I'm not confident to approve a TableGen back-end patch that could potentially change the behaviour in other targets.

I'm adding other people that touched the code / table files recently, and I'm hoping that other targets developers got the mail via the commits list and will chime in if necessary.

cheers,
--renato