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

Luke Kenneth Casson Leighton lkcl at lkcl.net
Tue Aug 3 13:08:31 BST 2021


On 8/2/21, Jacob Lifshay <programmerjake at gmail.com> wrote:
> On Sun, Aug 1, 2021, 17:41 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
>> 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
> following:
> i32 a, b; // globals
> // ...
> while(a > 2) {
>     if(b < 5)
>         f();
>     else
>         g();
>     h();
> }
> 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()) {
>         f(if_pred);
>     }
> label1:
>     pred else_pred = loop_pred & ~if_pred;
>     if(else_pred.any()) {
>         g(else_pred);
>     }
>     h(loop_pred);
> }
>
> 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
> skip:
> // 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.
>
> Jacob
>
>>
> _______________________________________________
> Libre-soc-dev mailing list
> Libre-soc-dev at lists.libre-soc.org
> http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev
>



More information about the Libre-soc-dev mailing list