[Libre-soc-bugs] [Bug 558] gcc SV intrinsics concept
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Mon Jan 11 22:49:32 GMT 2021
https://bugs.libre-soc.org/show_bug.cgi?id=558
--- Comment #42 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #40)
> I think that CRs should be handled entirely by the gcc backend, they will
> have mask values allocated to them automatically.
in the "final" version (the final target) i could not agree more. results (all
results) can have a CR associated with them: when Vectorised this becomes a
Vector of associated CRs and i would anticipate there not being much in the way
of changes to gcc-ppc64 scalar code to transform it to support "scalar is now
vector yes even CRs"
we are however at a weird state where for the minimum amount of work we need an
interim step that at least gives developers such as Lauri, plus the
cryptoprimitives Grant proposal, a level just above assembler that does not
require 2 years of gcc development before they can even begin work.
to expect gcc to automatically support vectors-of-CRs unfortunately does
exactly that: places significant gcc work smack on the critical path.
> In the gcc frontend, masks
> are just bitvectors (basically a uint64_t with a different type).
ah that might work. ahh i know. each CR Vector is considered to be a Vector
of eq bits, a Vector of lt bits etc.
the uint64_t with different type you mention is:
bit 0 is CR0.eq
bit 1 is CR1.eq
etc
then in the crweirder intrinsic it takes these parameters:
* struct of 4 uint64_t named eqltgtso
* same as dest
* mode
* mask
(or, just 10 arguments, 4x uint64_t src, 4x dest)
this sounds very much like what Tim Forsyth was talking about. design the ISA
so that the compiler can understand it.
> masks are generated by using compare intrinsics and by using bit-wise logic
> ops on masks. masks can be cast to/from integers.
>
> the cr logic ops and the cr from int and cr to int ops are generated
> automatically by the instruction selector and by the register allocator.
it woule be spectacularly weird to be striping the CR eq/so/lt/gt bits across
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list