﻿<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta charset="utf-8" />
  <title>Establishing a direction for SIMD-enabled functions</title>
</head>
<body>
  <table border="1">
    <tbody>
      <tr>
	<th>Doc. No.:</th>
	<td>P0601R0</td>
      </tr>
      <tr>
	<th>Date:</th>
	<td>2017-02-06</td>
      </tr>
      <tr>
	<th>Reply to:</th>
	<td><a href="mailto:clark.nelson@intel.com">Clark
	  Nelson</a></td>
      </tr>
      <tr>
	<th>Audience:</th>
	<td>SG1, EWG</td>
      </tr>
    </tbody>
  </table>
  <h1>Establishing a direction for SIMD-enabled functions</h1>
  <h2>Background</h2>
  <p><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3831.pdf">N3831</a>
    (from 2014, presented at the first Issaquah meeting)
    proposed SIMD-enabled functions,
    a declaration of which would include one or more
    <var>simd-specifier</var>s,
    each introduced by the <code>simd</code> 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:</p>
  <ul>
    <li>a constraint on the chunk size for the variant;</li>
    <li>whether the variant should be masked, or unmasked,
      or both;</li>
    <li>for each parameter (including <code>this</code>),
      whether the values in adjacent iterations should be uniform,
      or linear, the default being neither (i.e. independent).
    </li>
  </ul>
  <p>In the proposal,
    a <var>simd-specifier</var> made no contribution
    to the type of the function.</p>
  <p>In response, concerns were expressed about the ability
    to use SIMD variants in the same ways that &ldquo;classic&rdquo;
    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.</p>
  <p>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.</p>
  <p>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.</p>
  <h2>Going forward</h2>
  <p>One interesting question is whether the sentiment
    in SG1 in Issaquah,
    to augment the type system,
    was representative of the whole of WG21.</p>
  <p>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.</p>
  <p>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.</p>
</body>
</html>
