[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 #18 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #17)
> (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 instructions.  once through
> that phase a simple string-matching phase (in binutils) can remove that.

the problem is *not* at the assembly level, the problem is in the GCC IR level,
where everything is represented in a totally different way using things like
Static-Single-Assignment form, and fundamentally different than just a munged
assembly string. It's at the GCC IR level where all the optimizations are
performed, and they need to have all operations represented, either in some
opaque form (like I was proposing by using intrinsics *in the IR*) or in a form
where all the optimizers are aware of the semantics and know that the
instructions behave differently.
> 
> 
> > > 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.

Sorta yes, though having the compiler detect that particular pattern is quite
easy.

remember, the compiler goes through that pattern matching layer (instruction
selection) for all instructions. Every instruction (ignoring inline assembly)
is generated as the result of matching some pattern -- so all we do is add
patterns for vector-scalar ops instead of only having vector-vector patterns.
It's really that trivial.
> 
> 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

so, we have aes step be the first ALU op we implement :) the rest should be
relatively easier once we have 1 working, since it's mostly copy/paste.

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