Displaying 3 results from an estimated 3 matches for "d23646".
2016 Sep 19
3
[arm, aarch64] Alignment checking in interleaved access pass
Hi,
As a follow up to Patch D23646 <https://reviews.llvm.org/D23646>, I'm
trying to figure out if there should be an alignment check and what the
correct approach is.
Some background:
For stores, the pass turns:
%i.vec = shuffle <8 x i32> %v0, <8 x i32> %v1,
<0, 4, 8, 1, 5, 9, 2, 6, 10, 3,...
2016 Oct 10
2
[arm, aarch64] Alignment checking in interleaved access pass
...ases
as well.
> One way to test the back-end pattern matching is to emit textual IR
> and manually change it, removing the intrinsics, or changing the
> shuffles and see what happens after `opt`.
>
Yes, I did that with some of the codes generated by Halide, it's what led
to patch D23646 to extend the patterns. The new code being generated is the
"expected" one.
Also, benchmarking some of their apps showed that llvm's pass (after the
patch) does the job as well as the custom code generation they were using
before. (Note, that Halide's code generation was written b...
2016 Oct 10
2
[arm, aarch64] Alignment checking in interleaved access pass
Hi Renato,
Thank you for the answers!
First, let me clarify a couple of things and give some context.
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)
The examples you gave come mostly from loop vectorization, which, as I
understand it, was the reason for adding the