[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 #5 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #2)
> I think the intrinsics should be designed differently and share their syntax
> with the clang version:

what you propose is a massive amount of work, and is based on the
(equally-as-harmful-as-SIMD) principle of "one vector instruction, one
intrinsic".

given the huge amounts of time involved it also makes it impractical to apply
for a grant.

also whilst that's fine for llvm, which is going to have a huge amount of work
done by other teams (robin and simon amongst them), and be well-suited to
SPIR-V, the intrinsics added for gcc rvv take a different approach: barely
above assembler-level.

the sheer overwhelming quantity of intrinsics that you propose is precisely and
exactly what i do not see as being a good idea: it's the "one vector
instruction, one intrinsic" harmful principle, which spirals out of control.

additionally, gcc works on a completely different design principle from llvm,
which makes the llvm intrinsics concept harder to apply... because the
infrastructure isn't there.

SV is an abstraction layer that is supposed to be "easy" to insert into
hardware, and simulators.  binutils also turns out to be (reasonably)
straightforward as well.

up until i saw the rvv gcc work i was thinking that compilers would be excluded
from that list.

what i'd like to see is a "just-above-assembler" level that does *not* add
massive numbers of intrinsics: instead takes context from associated variables
and overloads scalar "add" or "mul" to simply be... vector "add" and vector
"mul", because it reflects how SV works.

done.

and the stunning thing is: there's not even any need to change the rest of the
compiler (except to add the svp64 prefix).  the *standard scalar add* is
inherently vectorised by virtue of the context.

no intrinsic vector mul.

no intrinsic vector add

no intrinsic scalar-vector mul

no intrinsic scalar-vector add

no intrinsic vector mul.

no intrinsic vector add

no intrinsic vector-scalar mul

no intrinsic vector-scalar add

you see where that's going?  total nightmare.  literally hundreds, getting on
for *thousands* of intrinsics.

no.

have the *variables* be marked as scalar or vector.  assume that the
*developer* is intelligent enough to mark them correctly.

where this gets hair-raising is when vec2/3/4 and swizzle is introduced.  there
i believe it may be solved with a union / struct.  not sure yet.

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