Establishing a direction for SIMD-enabled functions

Background

N3831 (from 2014, presented at the first Issaquah meeting) proposed SIMD-enabled functions, a declaration of which would include one or more simd-specifiers, each introduced by the simd keyword and containing zero or more clauses specifying aspects of a SIMD variant of the function. The proposed clauses/aspects of a SIMD variant (all optional) included:

• a constraint on the chunk size for the variant;
• whether the variant should be masked, or unmasked, or both;
• for each parameter (including this), whether the values in adjacent iterations should be uniform, or linear, the default being neither (i.e. independent).

In the proposal, a simd-specifier made no contribution to the type of the function.

In response, concerns were expressed about the ability to use SIMD variants in the same ways that “classic” function overloads can be used. In particular, some people wanted to be able to take the address of a specific SIMD variant of a function. It was generally believed that, to support this, information about SIMD variants would need to become part of the function's type.

The additional information associated with a function's type would presumably include not only the simple flag indicating that the function is declared to be SIMD-enabled, but also the complete set of declared SIMD variants, each one with complete information about the aspects either defaulted or specified by the clauses present.

It could, very reasonably, be argued that that would be an awful lot of information to add to the type system, and be questioned whether the benefit would be worth the cost. This trade-off was not explicitly explored in SG1 in Issaquah, but significantly greater support was expressed for adding this information to the type system than for the proposal in N3831.

Going forward

One interesting question is whether the sentiment in SG1 in Issaquah, to augment the type system, was representative of the whole of WG21.

Another interesting question is whether the WG21 consensus would prefer to describe SIMD variants in the source using attributes, rather than a new keyword, especially if there is not consensus to augment the type system.

My belief is that it would be productive to have explicit discussion of these trade-offs. From my perspective, it would be preferable to have this discussion before doing the work to produce a complete proposal detailing the impact of augmenting the type system for this purpose, to get some idea of the probability of consensus in advance. Ideally, that discussion should include a broad cross-section of the committee, and not just the SG1 experts most interested in SIMD programming; a joint session between SG1 and EWG would perhaps be the appropriate forum.