<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:Calibri;
        color:windowtext;}
span.msoIns
        {mso-style-type:export-only;
        mso-style-name:"";
        text-decoration:underline;
        color:teal;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:595.0pt 842.0pt;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body bgcolor="white" lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri;mso-fareast-language:EN-US">Hi James,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri;mso-fareast-language:EN-US">With our goal of making scalable vectors a first class type we already want to change the IR to incorporate "vscale" as part of the printed type (i.e. it's the
 "n" in "<n x 4 x i32>").  For this reason it makes sense to us if the isolated representation of "n" (i.e. vscale) is also treated as first class because the two representations go hand in hand.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri;mso-fareast-language:EN-US">The above is the stylistic answer but from a more practical point of view there will be many instances where "vscale" gets queried.  Folds that currently exist
 for ConstantInt will need to have "vscale" variants.  We concluded using an intrinsic would pollute the code base a lot more in the long run when compared to the new constant approached.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri;mso-fareast-language:EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri;mso-fareast-language:EN-US">Paul!!!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:Calibri;color:black">From: </span>
</b><span style="font-family:Calibri;color:black">llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of James Molloy via llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Reply-To: </b>James Molloy <james@jamesmolloy.co.uk><br>
<b>Date: </b>Thursday, 24 November 2016 at 20:49<br>
<b>To: </b>Graham Hunter <Graham.Hunter@arm.com>, "llvm-dev@lists.llvm.org" <llvm-dev@lists.llvm.org><br>
<b>Cc: </b>nd <nd@arm.com>, Will Lovett <Will.Lovett@arm.com><br>
<b>Subject: </b>Re: [llvm-dev] [RFC] Supporting ARM's SVE in LLVM<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Hi Graham,<br>
<br>
One high level comment without reading the patchset too much - it seems 'vscale' in particular could be just as easy to implement as an intrinsic, which would be a less invasive patch.
<br>
<br>
Is there a reason you didn't go down the intrinsic route?<br>
<br>
James<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, 24 Nov 2016 at 15:39, Graham Hunter via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Hi,<br>
<br>
Paul Walker has now uploaded the first set of IR support patches to phabricator, which use our revised design. We managed to remove the need for new instructions for basic scalable vectorization in favor of adding two new constant classes; here's a subset of
 the revised documentation describing just those constants:<br>
<br>
## *vscale*<br>
<br>
### Syntax:<br>
<br>
> `vscale`<br>
<br>
### Overview:<br>
<br>
This complex constant represents the runtime value of `n` for any scalable type<br>
`<n x m x ty>`. This is primarily used to increment induction variables and<br>
generate offsets.<br>
<br>
### Interface:<br>
<br>
```cpp<br>
  Constant *VScaleValue::get(Type *Ty);<br>
```<br>
<br>
### Example:<br>
<br>
The following shows how an induction variable would be incremented for a<br>
scalable vector of type `<n x 4 x i32>`.<br>
<br>
```llvm<br>
  %index.next = add nuw nsw i64 %index, mul (i64 vscale, i64 4)<br>
```<br>
<br>
## *stepvector*<br>
<br>
### Syntax:<br>
<br>
> `stepvector`<br>
<br>
### Overview:<br>
<br>
This complex constant represents the runtime value of a vector of increasing<br>
integers in the arithmetic series:<br>
<br>
> `<0, 1, 2, ... num_elements-1>`<br>
<br>
This is the basis for a scalable form of vector constants. Adding a splat<br>
changes the effective starting point, and multiplying changes the step. The<br>
main uses for this are:<br>
<br>
* Predicate creation using vector compares for fully predicated loops (see also:<br>
  [*propff*](#propff), [*test*](#test)).<br>
* Creating offset vectors for gather/scatter via `getelementptr`.<br>
* Creating masks for `shufflevector`.<br>
<br>
For the following loop, a `stepvector` constant would be added to a splat of the<br>
loop induction variable to create the data vector to store:<br>
<br>
```cpp<br>
  unsigned a[LIMIT];<br>
<br>
  for (unsigned i = 0; i < LIMIT; i++) {<br>
    a[i] = i;<br>
  }<br>
```<br>
<br>
### Interface:<br>
<br>
```cpp<br>
  Constant *StepVectorValue::get(Type *Ty);<br>
```<br>
<br>
### Example:<br>
<br>
The following shows the construction of a scalable vector of the form<br>
<start, start-2, start-4, ...>:<br>
<br>
```llvm<br>
  %elt = insertelement <n x 4 x i32> undef, i32 %start, i32 0<br>
  %widestart = shufflevector <n x 4 x i32> %elt, <n x 4 x i32> undef, <n x 4 x i32> zeroinitializer<br>
  %step = insertelement <n x 4 x i32> undef, i32 -2, i32 0<br>
  %widestep = shufflevector <n x 4 x i32> %step, <n x 4 x i32> undef, <n x 4 x i32> zeroinitializer<br>
  %stridevec = mul <n x 4 x i32> stepvector, %widestep<br>
  %finalvec = add <n x 4 x i32> %widestart, %stridevec<br>
```<br>
<br>
<br>
<br>
<br>
Current patch set:<br>
<a href="https://reviews.llvm.org/D27101" target="_blank">https://reviews.llvm.org/D27101</a><br>
<a href="https://reviews.llvm.org/D27102" target="_blank">https://reviews.llvm.org/D27102</a><br>
<a href="https://reviews.llvm.org/D27103" target="_blank">https://reviews.llvm.org/D27103</a><br>
<a href="https://reviews.llvm.org/D27105" target="_blank">https://reviews.llvm.org/D27105</a><br>
<br>
-Graham<br>
<br>
<br>
<br>
On 22/11/2016, 14:49, "Graham Hunter via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
<br>
    Hi Renato,<br>
<br>
    Sorry for the delay in responding. We've been busy rethinking some of our changes after the feedback we've received thus far (particularly from the devmeeting). The incremental patches will use our revised design(which should be less invasive), and I'll
 be updating our document to match.<br>
<br>
    On 16/11/2016, 12:46, "Renato Golin" <<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>> wrote:<br>
<br>
    >  This email is long and hard to read. I'm not surprised no one replied<br>
    >  yet. I think your PDF attached is a good start away from the<br>
    >  complexity, but we're not going to get far if we try to do things in<br>
    >  one step.<br>
<br>
    >  Based on your repository, the number of changes is so great, and the<br>
    >  changes so invasive, that we really should look back at what we need<br>
    >  to do, one step at a time, and only perform the refactoring changes<br>
    >  that are needed for each step.<br>
<br>
    We don't intend to do this all in one go; we fully expect that we'll need to refactor a few times based on community feedback as we incrementally add support for scalable vectors.<br>
<br>
    >  > * This is a warts-and-all release of our development tree, with plenty of TODOs and unfinished experiments<br>
    >  > * We haven't posted our clang changes yet<br>
    ><br>
    >  I don't mind FIXMEs or TODOs, but I did see a lot of spurious name<br>
    >  changes, enum value moves (breaking old binaries) and a lot of new<br>
    >  high-level passes (LoopVectorisationAnalysis) which will need a long<br>
    >  review on their own before we even start thinking about SVE.<br>
    ><br>
    >  I recommend you guys separate the refactoring from the implementation<br>
    >  and try to upstream the initial and uncontroversial refactorings (name<br>
    >  changes, etc), as well as move out the current functionality into new<br>
    >  passes, so then you can extend for SVE as a refactoring, not<br>
    >  move-and-extend in the same pass.<br>
<br>
    So our highest priority is getting basic support for SVE into the codebase (types, codegen, assembler/disassembler, simple vectorization); after that is in, we'll be happy to discuss our other changes like separating out loop vectorization legality, controlling
 loops via predication, or adding search loop vectorization.<br>
<br>
    >  We want to minimise the number of changes, so that we can revert<br>
    >  breakages more easily, and have a steady progress, rather than a<br>
    >  break-the-world situation.<br>
<br>
    Same for us. The individual patches will be relatively small, this repo was just for context if needed when discussing the smaller patches.<br>
<br>
    >  Finally, *every* test change needs to be scrutinised and guaranteed to<br>
    >  make sense. We really dislike spurious test changes, unless we can<br>
    >  prove that the test was unstable to being with, in which case we<br>
    >  change it to a better test.<br>
<br>
    Yep, makes sense.<br>
<br>
    Thanks,<br>
<br>
    -Graham<br>
<br>
<br>
<br>
    _______________________________________________<br>
    LLVM Developers mailing list<br>
    <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
    <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>