[cfe-dev] [llvm-dev] RFC: First-class Matrix type

Renato Golin via cfe-dev cfe-dev at lists.llvm.org
Fri Oct 19 06:47:58 PDT 2018

On Thu, 18 Oct 2018 at 08:04, Bruce Hoult via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> The aim will always be to interchange loops so as to get unit stride in an underlying 1D vector. Which can be done directly.

I imagine that the information about the ABI would have been done
solely by the front-end, which includes compile-time constant padding
on all dimensions, making it feasible to add offsets when iterating
through matrix rows/cols in 1D.

If the padding is different or badly aligned, it would be the same
cost for the front-end to lower the right adds to induction at the
right time as it would be for the middle/back-end, but we already have
(all?) such decisions being made by the front-ends.

Even if we would try to simplify the IR codegen, to expose more
parallelism, the change could be an IR annotation on a new type of
scalar evolution (with arbitrary padding at arbitrary times), and not
necessarily a new type.

Someone mentioned reductions, but we already have reduction intrinsics
that deal with that:


Perhaps just adding more of those would satisfy all needs?

With regards to aliasing, couldn't the front-end just force no alias
when the "source code type" is guarantee to not alias, like Fortran?
If we carry that through the optimisation passes, then it should be
easy to not add unnecessary runtime checks.

Finally, I do agree that trickling all of that matrix-specific
knowledge to generic passes like the loop vectoriser, inliner, etc
would be perhaps too big and imperfect, but I haven't got it why a new
type would fix this, other than having to teach all passes about the
new type (which is the same cost as intrinsics).

An alternative would be a new, simpler pass, or even a simplified
VPlan, based on a quick analysis to check such patterns, guarded by
the existence of "matrix attributes" having ever being set by the
front-end, for example (just guessing here).


More information about the cfe-dev mailing list