[Mesa-dev] [PATCH 4/5] nir: Recognize mul(b2f(a), b2f(b)) as a logical AND.

[Matt Turner]

On Wed, Mar 18, 2015 at 9:27 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> On Wed, Mar 18, 2015 at 8:59 PM, Connor Abbott <cwabbott0 at gmail.com> wrote:
>> On Wed, Mar 18, 2015 at 11:35 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>>>
>>> On Mar 18, 2015 8:32 PM, "Matt Turner" <mattst88 at gmail.com> wrote:
>>>>
>>>> On Wed, Mar 18, 2015 at 7:39 PM, Jason Ekstrand <jason at jlekstrand.net>
>>>> wrote:
>>>> > On Wed, Mar 18, 2015 at 11:37 AM, Matt Turner <mattst88 at gmail.com>
>>>> > wrote:
>>>> >> Transform this into b2f(and(a, b)).
>>>> >>
>>>> >> total instructions in shared programs: 6205448 -> 6204391 (-0.02%)
>>>> >> instructions in affected programs:     284030 -> 282973 (-0.37%)
>>>> >> helped:                                903
>>>> >> HURT:                                  6
>>>> >> ---
>>>> >>  src/glsl/nir/nir_opt_algebraic.py | 2 ++
>>>> >>  1 file changed, 2 insertions(+)
>>>> >>
>>>> >> diff --git a/src/glsl/nir/nir_opt_algebraic.py
>>>> >> b/src/glsl/nir/nir_opt_algebraic.py
>>>> >> index ef855aa..f956edf 100644
>>>> >> --- a/src/glsl/nir/nir_opt_algebraic.py
>>>> >> +++ b/src/glsl/nir/nir_opt_algebraic.py
>>>> >> @@ -95,6 +95,8 @@ optimizations = [
>>>> >>     (('fsat', a), ('fmin', ('fmax', a, 0.0), 1.0),
>>>> >> 'options->lower_fsat'),
>>>> >>     (('fsat', ('fsat', a)), ('fsat', a)),
>>>> >>     (('fmin', ('fmax', ('fmin', ('fmax', a, 0.0), 1.0), 0.0), 1.0),
>>>> >> ('fmin', ('fmax', a, 0.0), 1.0)),
>>>> >> +   # Emulating booleans
>>>> >> +   (('fmul', ('b2f', a), ('b2f', b)), ('b2f', ('iand', a, b))),
>>>> >
>>>> > Those are only equivalent if the sources are known booleans.
>>>> > Otherwise, no dice.
>>>>
>>>> Well... they're the source of a b2f. Are you saying that's not sufficient?
>>>
>>> No, that's not.  Fortunately, @bool should solve it for you in all of the
>>> cases you care about.
>>
>> I think Matt has a point here. There's not much point in defining how
>> b2f should work for things that aren't bools, and I'm fine with
>> transforms that produce "bad"/undefined results when the input isn't 0
>> or ~0. We should never get into that situation anyways. This is
>> different from the issue that compare instructions always have to
>> produce 0 or ~0, although both do stem from the fact that NIR doesn't
>> have a bool type.
>
> Ok... In that case, we need to define some things better.  For
> instance, bcsel is currently defined as "if nonzero do this else that"
> which is very different from "if ~0 do this else if 0 do that else...

The only place I see any comments about bcsel is in nir_opcodes.py, which says:

# Conditional Select
#
# A vector conditional select instruction (like ?:, but operating per-
# component on vectors). There are two versions, one for floating point
# bools (0.0 vs 1.0) and one for integer bools (0 vs ~0).

I'd be great if we documented the opcodes much in the same way TGSI's
opcodes are documented. I get the sense that the documentation you're
referring to is only in your brain. :)

> who knows?"  I'm ok with either but we need to be clear.  If we stop
> using the sloppy version that may mean that when translating from
> other source languages that may not be strongly typed we'll have to do
> a ine with zero to fix it up.
> --Jason