teach kAND/kOR to optimize &(1) and |(1)

[oleg-nesterov]

These BinOp's can optimize out the isMinusOne/isZero operands, but since the xxxNeutral/Absorbing predicates take a single argument they can't check another operand and take isOne() into account, so this patch adds the brute force check into simplification.

Random example,

process = _ <: ==(1) | ==(2) <: &(1==1), |(2!=3);

compiles to

float fTemp0 = float(input0[i0]);
int iTemp1 = (fTemp0 == 1.0f) | (fTemp0 == 2.0f);
output0[i0] = FAUSTFLOAT(iTemp1 & 1);
output1[i0] = FAUSTFLOAT(iTemp1 | 1);

after this patch we have

float fTemp0 = float(input0[i0]);
output0[i0] = FAUSTFLOAT((fTemp0 == 1.0f) | (fTemp0 == 2.0f));
output1[i0] = FAUSTFLOAT(1);

Should the new isSigBool() function have the "int max_recursion" argument?

[sletz]

Thanks, should we also consider optimising&(0)and |(0) ?

[oleg-nesterov]

Hi,

I can't check this right now, but I think this is not needed. I think that absorbing/neutral
predicates (can't recall the correct names right now) should already take care about this
case.

At least this is what I had in mind when I wrote this patch, and I even tried to document
this in the changelog, please see the note about isZero() operands at the start.

Thanks,

[oleg-nesterov]

I'm afraid I wasn't clear, let me add more spam.

Lets suppose we have "expr & 0". In this case we don't care about "expr", result is 0
and iirc simplification() already does this using the absorbing (or neutral, I can confuse
the names ;)

But "expr & 1" is more difficult, we can remove "& 1" sometimes, but we need to inspect
this "expr". This is what the patch does, and this is what neutral/absorbing can't do because
they accept a single argument: 0 or 1 in these cases.

[sletz]

OK right, I will test ASAP, but possible not before next week