[Libre-soc-dev] [RFC] SVP64 on branch instructions

Jacob Lifshay programmerjake at gmail.com
Mon Aug 2 08:42:27 BST 2021

On Sun, Aug 1, 2021, 17:41 Luke Kenneth Casson Leighton <lkcl at lkcl.net>

> https://libre-soc.org/openpower/sv/branches/
> i created this page with various modes, i believe only "ALL/SOME" is
> needed because by inverting the BO test itself ~ALL and ~SOME are
> achieved.

Instead of "SOME", I'd call the mode "ANY" -- it's more specific.
Alternatively we could call the modes reduce-and/reduce-or, since that's
what they actually are.

GPU code could benefit from having the semantics be where the SVP64
predicate (either Int or CR) tells the branch instruction which CR fields
it should use, where zero bits in the SVP64 predicate cause the
corresponding CR fields to be ignored. Since the ignored bits cause ~ALL
and ~ANY to no longer be redundant afaict, we will want to add them back
in. This will allow saving instructions in nested SIMT code like the
i32 a, b; // globals
// ...
while(a > 2) {
    if(b < 5)
which compiles to something like:
vec<i32> a, b;
// ...
pred loop_pred = a > 2;
while(loop_pred.any()) {
    pred if_pred = loop_pred & (b < 5);
    if(if_pred.any()) {
    pred else_pred = loop_pred & ~if_pred;
    if(else_pred.any()) {

in the else_pred part (after label1 above), we could write it like so
(wrong asm syntax, but you get the point):
// loop_pred could be stored in r30 or something -- out-of-the-way of f(),
g(), and h()
// skip extra instructions if not(any non-ignored bit in else_pred is set),
// the un-prefixed branch instruction is just: `bc ~if_pred, skip`
bc reduce_mode=~ANY, svp64_pred=loop_pred, ~if_pred, skip
// compute else_pred without loop_pred being forced to be in a CR,
// this only works if else_pred is the same CR registers as if_pred
// and it relies on all zero bits in loop_pred also being zeros in if_pred
crnot else_pred, if_pred, svp64_pred=loop_pred
// g(else_pred) inlined here
// h(loop_pred) inlined here
// code for while loop...

The above would take additional instructions if the semantics of br were
instead defined as currently in the wiki, instead of my proposal.



More information about the Libre-soc-dev mailing list