<div dir="ltr">Hi Renato,<div><br></div><div>Thank you for the answers!</div><div><br></div><div>First, let me clarify a couple of things and give some context.</div><div><br></div><div>The patch it looking at VSTn, rather than VLDn (stores seem to be somewhat harder to get the "right" patterns, the pass is doing a good job for loads already)</div><div><br></div><div>The examples you gave come mostly from loop vectorization, which, as I understand it, was the reason for adding the interleaved access pass. I'm looking at a different usecase. The code in question is generated by a DSL (Halide), and it's directly generating LLVM bitcode. The computations do come originally from loops, but they are pre-processed by Halide, followed by vector code generation as bitcode. The patters I'm targeting are not generated AFAIK from the loop vectorization or SLP passes.</div><div><br></div><div>Now, for ARM archs Halide is currently generating explicit VSTn intrinsics, with some of the patterns I described, and I found no reason why Halide shouldn't generate a single shuffle, followed by a generic vector store and rely on the interleaved access pass to generate the right intrinsic. </div><div>Performance-wise, it is worth using the VSTns in the scenarios they encounter, it's mostly a question of where they get generated. </div><div><br></div><div>The alignment question is orthogonal to the patch up for review. There was no alignment check before, and I didn't have enough background of the architectures to conclude if this was needed or not. I added a simple check to test if this would make any difference and some of the ARM tests started failing. The break just meant that the interleaved access pass was not replacing the "shuffle+store" with the "vstn" so the checks were failing.<br></div><div>If the alignment is not an issue, it simplifies things.</div><div><br></div><div>Also, thank you for the reference!</div><div><br></div><div>Best,</div><div>Alina</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 8, 2016 at 6:26 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 19 September 2016 at 21:52, Alina Sbirlea via llvm-dev<br>
<span class=""><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> The question I'm trying to get answered if there should have been an<br>
> alignment check for the original pass, and, similarly, if there should be an<br>
> expanded one for the more general pattern.<br>
<br>
</span>Hi Alina,<br>
<br>
IIRC, the initial implementation was very simple and straightforward<br>
to make use of VLDn instructions on ARM/AArch64 NEON.<br>
<br>
Your patterns allow simple vector instructions in the trivial case,<br>
but not in the cases where VLDn would make a difference.<br>
<br>
The examples were:<br>
<br>
for (i..N)<br>
  out[i] = in[i] * Factor; // R<br>
  out[i+1] = in[i+1] * Factor; // G<br>
  out[i+2] = in[i+2] * Factor; // B<br>
<br>
This pattern is easily vectorised on most platforms, since loads, muls<br>
and stores are the exact same operation. which can be combined.<br>
<br>
for (i..N)<br>
  out[i] = in[i] * FactorR; // R<br>
  out[i+1] = in[i+1] * FactorG; // G<br>
  out[i+2] = in[i+2] * FactorB; // B<br>
<br>
This still can be vectorised easily, since the Factor vector can be<br>
easily constructed.<br>
<br>
for (i..N)<br>
  out[i] = in[i] + FactorR; // R<br>
  out[i+1] = in[i+1] - FactorG; // G<br>
  out[i+2] = in[i+2] * FactorB; // B<br>
<br>
Now it gets complicated, because the operations are not the same. In<br>
this case, VLDn helps, because you shuffle [0, 1, 2, 3, 4, 5] -> VADD<br>
[0, 3] + VSUB [1, 4] + VMUL [2, 5].<br>
<br>
Your case seems to be more like:<br>
<br>
for (i..N)<br>
  out[i] = in[i] * FactorR; // R<br>
  out[i+4] = in[i+4] * FactorG; // G<br>
  out[i+8] = in[i+8] * FactorB; // B<br>
<br>
In which VLDn won't help, but re-shuffling the vectors like the second<br>
case above will.<br>
<br>
Even this case:<br>
<br>
for (i..N)<br>
  out[i] = in[i] + FactorR; // R<br>
  out[i+4] = in[i+4] - FactorG; // G<br>
  out[i+8] = in[i+8] * FactorB; // B<br>
<br>
can work, if the ranges are not overlapping. So, [0, 4, 8] would work<br>
on a 4-way vector, but [0, 2, 4] would only work on a 2-way vector.<br>
<span class=""><br>
<br>
> In the example above, I was looking to check if the data at positions 4, 16,<br>
> 32 is aligned, but I cannot get a clear picture on the impact on performance<br>
<br>
</span>On modern ARM and AArch64, misaligned loads are not a problem. This is<br>
true at least from A15 onwards, possibly A9 (James may know better).<br>
<br>
If your ranges overlap, you may be forced to reduce the vectorisation<br>
factor, thus reducing performance, but the vectoriser should be able<br>
to pick that up from the cost analysis pass (2-way vs 4-way).<br>
<span class=""><br>
<br>
> Also, some preliminary alignment checks I added break some ARM tests (and<br>
> not their AArch64 counterparts). The cause is getting "not fast" from<br>
> allowsMisalignedMemoryAccesses<wbr>, from checking hasV7Ops.<br>
<br>
</span>What do you mean by "break"? Bad codegen? Slower code?<br>
<span class=""><br>
<br>
> Side question for Tim and other ARM folks, could I get a recommendation on<br>
> reading material for performance tuning for the different ARM archs?<br>
<br>
</span>ARM has a list of manuals on each core, including optimisation guides:<br>
<br>
<a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.set.cortexa/index.html" rel="noreferrer" target="_blank">http://infocenter.arm.com/<wbr>help/index.jsp?topic=/com.arm.<wbr>doc.set.cortexa/index.html</a><br>
<br>
cheers,<br>
--renato<br>
</blockquote></div><br></div></div>