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