On 8/3/23 01:04, Richard Biener wrote:
On Wed, Aug 2, 2023 at 4:08 PM Manolis Tsamis <manolis.tsa...@vrull.eu> wrote:
Hi all,
I'm pinging to discuss again if we want to move this forward for GCC14.
I did some testing again and I haven't been able to find obvious
regressions, including testing the code from PR86270 and PR70359 that
Richard mentioned.
I still believe that zero can be considered a special case even for
hardware that doesn't directly benefit in the comparison.
For example it happens that the testcase from the commit compiles to
one instruction less in x86:
.LFB0:
movl (%rdi), %eax
leal 1(%rax), %edx
movl %edx, (%rdi)
testl %eax, %eax
je .L4
ret
.L4:
jmp g
vs
.LFB0:
movl (%rdi), %eax
addl $1, %eax
movl %eax, (%rdi)
cmpl $1, %eax
je .L4
ret
.L4:
xorl %eax, %eax
jmp g
(The xorl is not emitted when testl is used. LLVM uses testl but also
does xor eax, eax :) )
Although this is accidental, I believe it also showcases that zero is
a preferential value in various ways.
I'm running benchmarks comparing the effects of this change and I'm
also still looking for testcases that result in problematic
regressions.
Any feedback or other concerns about this are appreciated!
My comment from Apr 24th still holds, IMO this is something for
instruction selection (aka the ISEL pass) or the out-of-SSA tweaks
we do during RTL expansion (see insert_backedge_copies)
I'm still generally supportive of biasing to zero, but as Richi has
noted the current implementation needs to be pushed further back into
the pipeline, preferably all the way to isel or gimple->rtl expansion.
Jeff
