[llvm-dev] [RFC] Vector Predication

[Luke Kenneth Casson Leighton via llvm-dev]

On Mon, Feb 4, 2019 at 9:41 PM Robin Kruppe <robin.kruppe at gmail.com> wrote:
> On Mon, 4 Feb 2019 at 22:04, Simon Moll <moll at cs.uni-saarland.de> wrote:
>> And there is a native 16 x 16 element load (VLD2D) on SX-Aurora, which may be represented as:
>>
>>     <scalable 256 x double> llvm.evl.gather.nxv16f64(<scalable 16 x double*> %Ptr, <scalable 16 x i1> mask %M, i32 vlen 16)
>
> In contrast to the above I can't very well say one should write this as a gather of i1024, but it also seems like a rather specialized instruction (presumably used for blocked processing of matrices?) so I can't say that this on its own motivates me to complicate a proposed core IR construct.

 i concur: any architecture that has fixed (SIMD-style) processing
widths is basically hell for any compiler to deal with in a generic
way.  architecturally-fixed element widths really do not fit into the
arbitrary-width vector processing paradigm, and i foresee efforts to
try resulting in design conflict and ultimately failure.

 can i therefore recommend that variable-length ISAs be given top
priority in the design, so that there is the possibility for various
variable-length architectures to do near-direct highly optimised
translations, and leave SIMD-style (fixed width) architectures to
continue the long-standing well-established practice of creating
"special-case / corner-case / cleanup" code?

 (with apologies to proponents of SX-Aurora, MMX, SSE and other
fixed-width SIMD-style architectures...)

l.