[Libre-soc-bugs] [Bug 558] gcc SV intrinsics concept

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=558

--- Comment #9 from Alexandre Oliva <oliva at libre-soc.org> ---
There's nothing "just" about getting GCC to turn scalar insns into
vector ones, I'm afraid.

Register allocation is largely driven by insn definitions and their
requirements, and the definitions carry machine modes requirements that
establish data size and what kind of data it is, which establish whether
the data fits at all in a register file, and how many registers of that
file are needed to hold an object of that machine mode.

The prefix also alters insn length, that influences computations about
branch distances and constant pool placement, and scheduling (units,
latency) is very significantly affected by the fact that vector-prefixed
insns are actually multiple insns issued in sequence.


Though GCC vectorizers can turn certain loops and sequences of
instructions into vectors, they largely rely on the available vector
modes.

It doesn't seem unreasonable to define all of the available combinations
of vector lengths and component modes as vector machine modes, and to
define the vector versions of scalar insns as template insns,
parameterized with the lengths and modes over each operand.

That's quite some work, though not particularly challenging.

What I'm not sure about how to model is the vector length: though maxvl
is a compile time constant, vl is dynamic, and it may vary; it needs a
register of its own, for us to be able to represent setting it up, and
modifying it as a side effect, but it has to somehow be constrained to
the compiler's notion of what the maxvl is for the insn, since that is
what guides register allocation.


There is a possibility of introducing vector-prefixed variants
mechanically, as modified versions of existing scalar insns, using
machinery similar to the way conditional insns are introduced on ARM,
but I'd have to look into that to see whether it's really viable.


Intrinsics can give direct access to features that the vectorizer can't
(yet?) introduce on its own; I suppose masks and twin predicates might
be missing in general, though I'd have to look at how conditionals are
dealt with in the vectorizer to tell for sure.

Introducing intrinsics that map more or less directly to the
corresponding versions of vector insns templates is probably, including
the extra prefix-only operands, is not unreasonable.  It is quite some
work but, again, not particularly challenging, and quite possibly
automatable.


My suggested approach is to start out with one scalar insn and a handful
of vector lengths, say 32-bit integer add with wrap-around, and try to
get them used on vectors, as intrinsics and through the vectorizer, and
from that try to estimate the amount of effort to cover more
possibilities.

-- 
You are receiving this mail because:
You are on the CC list for the bug.