Displaying 3 results from an estimated 3 matches for "acfea6f1".
2018 Jan 17
1
Does it make sense to upstream some MVT's?
...n 7.7 pg
> 579-592). I'll bring my copy to the next Bay Area LLVM Social if folks want
> to take a look.
>
>
>
> -- Sean Silva
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180117/acfea6f1/attachment.html>
2018 Jan 17
0
Does it make sense to upstream some MVT's?
Hi Sean,
I had to add âv16f16â to our out-of-tree target, and this was to primarily to allow me to express lowering for all the OpenCL types (well, except for the âv3Tâ types).
The trend does seem to be towards larger bit-width SIMD registers, and as you say this will increase in time; but perhaps instead of using a discrete enumeration combined with additional entries in several
2018 Jan 17
3
Does it make sense to upstream some MVT's?
Hi,
Our backend for Pixel Visual Core uses some MVT's that aren't upstream.
Does it make sense to upstream them? I figure that as architectures get
wider, we'll eventually have "all" possible combinations of widths and
types, but on the other hand having code that isn't used by current
backends in tree isn't great.
These are the MVT's that we have added:
16x16