[Mesa-dev] [PATCH] st/mesa: make sure to create a "clean" bool when doing i2b

[Roland Scheidegger]

Am 11.05.2015 um 21:38 schrieb Ilia Mirkin:
> On Mon, May 11, 2015 at 3:29 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>> Reviewed-by: Roland Scheidegger <sroland at vmware.com>
>>
>> As for b2i I'm not really convinced using INEG is preferable there.
>> Generally I'd favor logic ops over arithmetic any day.
>> I suppose backend probably need to try to recognize such patterns anyway
>> for best performance (so that for instance things like b2i->i2b should
>> be no-ops), and I just don't see that INEG using AND instead would help
>> much there in general. But I don't really know...
> 
> Well, there are a number of instructions that can take "neg" modifiers
> (like add, mul, mad). None that can take "& 1" modifiers (although
> and/etc can take "not" modifiers). By the time things get to gallium,
> the bool-ness of variables is lost, so it can be tricky to figure if &
> 1 really means "b2i" or if it really means "random value & 1". I guess
> bool's are always produced by comparisons, so you could just key it
> off of whether the random value is produced by a set or not. [I'm
> already planning a similar hack for "& 1.0", where the set instruction
> can actually produce the 1.0 value directly if told so.]
> 
> I'm curious why you prefer bit manipulation over arithmetic? I have
> the opposite preference...
> 

That is mostly based on theory. bit-ops should be cheaper than
arithmetic (be it in terms of actual execution latency/throughput or if
not that in terms of energy needed for the computation at least). Of
course I may be biased here working on llvmpipe :-).
That said, since it's b2i using ineg may be quite reasonable, as the
result is going to be used as a int (hence somewhat likely you could
actually fold something with that negation). So I'm ok with that change
if you think it's better, though ideally we'd have some numbers how such
changes actually affect different drivers (like shader-db).

Roland