[Bug target/94892] (x >> 31) + 1 not getting narrowed to compare

[gabravier at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94892

--- Comment #4 from Gabriel Ravier  ---
Harald, for the specific code you wrote, I now see this from GCC :

f(int):
  test edi, edi
  js .L2
  jmp f1()
.L2:
  jmp f2()

So for that specific code, GCC has improved, though for the original test case
it has not. I must note, though, that this still means that either :
- GCC fails to properly optimize `(x >> 31) + 1`
- GCC fails to properly optimize my original test case

[Bug target/94892] (x >> 31) + 1 not getting narrowed to compare

[harald at gigawatt dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94892

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #3 from Harald van Dijk  ---
Changing the test slightly to

  inline int sign(int x)
  {
return (x >> 31) | ((unsigned)-x >> 31);
  }

  void f1(void);
  void f2(void);
  void f(int x)
  {
if (sign(x) > -1)
  f1();
else
  f2();
  }

shows at -O3 with LLVM:

  f:
testedi, edi
js  .LBB0_2
jmp f1
  .LBB0_2:
jmp f2

whereas GCC produces:

  f:
mov eax, edi
sar edi, 31
neg eax
shr eax, 31
or  edi, eax
cmp edi, -1
je  .L2
jmp f1
  .L2:
jmp f2

In that example, LLVM is doing much better.

[Bug target/94892] (x >> 31) + 1 not getting narrowed to compare

[gabravier at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94892

--- Comment #2 from Gabriel Ravier  ---
In that case, then, GCC is generating sub-optimal code for `(x >> 31) + 1`
alone since it optimises that to the same thing as LLVM

[Bug target/94892] (x >> 31) + 1 not getting narrowed to compare

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94892

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |target

--- Comment #1 from Andrew Pinski  ---
GCC's code gen is actually better than LLVM's here I think.