2013/6/3 Jeff Law <l...@redhat.com>:
> The counter to that argument of leaving it to the backend to recover the
> and-not for is that the backend doesn't typically see these as single bit
> operations which makes turning the relational back into an and-not sequence
> considerably more difficult.
>
> Do we consider this enough of an issue to want to avoid going down this
> path? (in which case we'll file the example code as a missed-opt PR and
> attach the code and pointer to this thread for future reference)
>

Hmm, my tests are showing (for targets with conditional set
instructions) and improvement even for none-conditional-branch code.

Sample code:

_Bool foo (_Bool a, _Bool b)
{
  _Bool r = a < b;
  return r;
}

_Bool boo (_Bool a, _Bool b)
{
  _Bool r = ~a & b;
  return r;
}

produces:

        .text
        .p2align 4,,15
        .globl  foo
        .def    foo;    .scl    2;      .type   32;     .endef
        .seh_proc       foo
foo:
        .seh_endprologue
        cmpb    %cl, %dl
        seta    %al
        ret
        .seh_endproc
        .p2align 4,,15
        .globl  boo
        .def    boo;    .scl    2;      .type   32;     .endef
        .seh_proc       boo
boo:
        .seh_endprologue
        movl    %ecx, %eax
        notl    %eax
        andl    %edx, %eax
        andl    $1, %eax
        ret

So it seems to be obvious that code gets much less costy as without
this optimization.

Kai

Reply via email to