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

[Jason Ekstrand]

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...
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