[PATCH] D57504: RFC: EVL Prototype & Roadmap for vector predication in LLVM

[Luke Kenneth Casson Leighton via Phabricator via llvm-commits]

lkcl added a comment.

> Certainly, that's why I say it's secondary and mostly a hint that something is amiss with "the current thinking". In fact, I am by now inclined to propose that Jacob and collaborators start out by expressing their architecture's operations with target-specific intrinsics that also use the attributes introduced here (especially since none of the typical vectorizers are equipped to generate the sort of code they want from scalar code using e.g. float4 types).

just so you know: we're not using a "typical vectoriser", we are writing our own, and it is very very specifically designed to accommodate the float3 and float4 datatypes.  it is a SPIR-V to LLVM-IR compiler (used by both OpenCL and 3D Shaders compatible with the Vulkan API).  to reiterate: we are *not* expecting to vector-augment or even use clang-llvm, rustlang-llvm or other vectoriser, we are *directly* translating SPIR-V IR into LLVM IR.

so LLVM IR having these vectorisation features is important (for the Kazan Project), yet, bizarrely, front-end support for vectorisation is *not* important (for the Kazan Project).

> Alternatively, use a dynamic vector length of <the length their architecture wants> * <how many elements each of the short vectors has> and fix it up in the backend.

remember that both RVV and SV support the exact same vscale (variable-length multiples of elements) concept.

so if EVL does not support vscale, it would be mandatory for *both* RVV *and* SV to carry out sub-optimal backend fixups.  that would mean in turn that both RVV and SV would be forced to create a copy of the predicate mask, multiplied out by the vscale length, and other associated significantly sub-optimal decisions.

whereas, for a SIMD-style architecture that doesn't *have* predication at all, they're *already* going to have to use gather/scatter, they're *already* sub-optimal, and taking vscale into account in the loop is a trivial backend modification.

effectively, the finest-grained features need to be exposed to the top-level API, whatever they are, otherwise architectures that have such features need to "dumb down" by way of back-end fixups, and the opportunity for LLVM to be a leading all-inclusive complier technology is lost.

now, at some point, we might ask ourselves "what the heck, why is everyone having to suffer just because of one particularly obtuse flexible feature that other architectures do not have??" which is a not very nice but quite reasonable way to put it... and the answer to that is: do we *really* want to encourage ISA architectural designers to keep things as they've always been [primarily SIMD]?


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57504/new/

https://reviews.llvm.org/D57504