[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 #17 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #8)
> (In reply to Luke Kenneth Casson Leighton from comment #5)
> > 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.
> 
> I'm pretty sure it is waay more complex than that, since the compiler has to
> accurately represent all code, and the easiest way to accurately represent
> new operations (which is what all SV ops are) is by using intrinsics, since
> they look just like opaque function calls to most the compiler, so it won't
> try to optimize them in a way that isn't valid with SV.

an easy way to deal with that is to add a string prefix to the instructions
inserted into the assembly stream.  svp64{something}.

this would stop them being treated as scalar insteuctions.

> > no intrinsic vector mul.
> > 
> > no intrinsic vector add
> > 
> > no intrinsic scalar-vector mul
> 
> I wasn't proposing having scalar-vector ops since those can be represented
> by _sv_mul(__sv_splat(lhs, ...), rhs, ...) and almost trivially
> pattern-matched at instruction selection time into the scalar-vector
> instructions.

this is a full-on compiler proposal.

if we put in a full-on gcc application for funding under the Assure Programme i
can guarantee it will be rejected.

the trick i am proposing is borderline but doable, and it works *only* if
cryptographic primitives are the *primary* focus of the Grant Application

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