[Mesa-dev] [PATCH 3/3] nir: Simplify ine/ieq(ineg(a), a) -> ine/ieq(a, 0)

[Ilia Mirkin]

On Thu, Aug 6, 2015 at 6:08 PM, Matt Turner <mattst88 at gmail.com> wrote:
> (Don't top quote)
>
> On Thu, Aug 6, 2015 at 7:22 AM, Boyan Ding <boyan.j.ding at gmail.com> wrote:
>> But, isn't -INT_MIN == INT_MIN?
>
> In C (-INT_MIN) is undefined since it relies on behavior of signed
> integer overflow.
>
> In GLSL though, I think you're right. The spec says that addition
> subtraction, and shift operations (weird to list shift operations)
> will wrap. Multiplication and division however do not -- when they
> overflow their results are undefined (per a clarification/change in
> the 4.30 spec).
>
> So yeah, I don't think this is safe.
>
> By the way, a good sanity check is to write a C function and compile
> with gcc and see if it performs the optimization you're implementing.
>
> bool int_cmp(int x) {
>     return -x == x;
> }
>
> 0000000000000000 <int_cmp>:
>    0: 89 f8                 mov    %edi,%eax
>    2: 01 f8                 add    %edi,%eax
>    4: 0f 94 c0             sete   %al
>    7: c3                   retq
>
> I'm not actually sure what it's doing, but the function does return
> true for INT_MIN.

Looks like it does (x + x) == 0. add sets the zero (aka equal) flag
bit, sete (aka setz) checks the contents of that flag bit. So it
doesn't optimize that into a x == 0 check.

  -ilia