[Bug tree-optimization/52285] [4.7 Regression] libgcrypt _gcry_burn_stack slowdown

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52285

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org, vmakarov at gcc
   ||dot gnu.org

--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-20 
11:13:33 UTC ---
void
foo (int x)
{
  char buf[64];
  do
{
  volatile char *p = buf;
  unsigned long l = sizeof buf;
  while (l)
{
  *p = 0;
  p++;
  l--;
}
  x -= sizeof buf;
}
  while (x  0);
}

is a testcase without tail call.  With r184317 we keep the buf[64] inside of
the loop, but unfortunately buf[64] is (reg:DI 20 frame) here (buf[0] is
frame-64), and therefore RTL lim doesn't do anything with it.
And when reload reloads that (reg:DI frame) into (minus:DI (reg:DI sp)
(const_int -8)), it doesn't place the lea before the loop, even when the
register pressure is low.  And no further pass does the loop invariant move
either.

I wonder if we shouldn't in RTL lim just load (frame) and other most likely
eliminable registers before the loop into some new pseudo (with REG_EQUIV) and
use it in the loop, I think if register pressure is high RA should
rematerialize those inside of the loop, shouldn't it?

[Bug tree-optimization/52285] [4.7 Regression] libgcrypt _gcry_burn_stack slowdown

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52285

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 
18:25:24 UTC ---
While it will slow down this exact testcase even more, I think tailr/tailc
passes should ignore CLOBBER stmts.

[Bug tree-optimization/52285] [4.7 Regression] libgcrypt _gcry_burn_stack slowdown

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52285

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 
18:39:57 UTC ---
This is also a libgcrypt bug, because clearly if it wants to burn some portion
of the stack (assuming for security reasons), then
1) if it doesn't prevent tail recursion or tail call to itself, it doesn't do
what it is trying to do, in particular it keeps overwriting with zeros the same
portion of memory over and over
2) even if it isn't tail recursion/call optimized, on most targets it will
still leave gaps on the stack not overwritten
So, all in all, quite questionable way of burning cycles in the crypto library.

[Bug tree-optimization/52285] [4.7 Regression] libgcrypt _gcry_burn_stack slowdown

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52285

--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 
18:50:27 UTC ---
Created attachment 26681
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26681
gcc47-pr52285.patch

Patch to ignore clobber stmts in tailc/tailr passes.  This turns this testcase
back into a loop, for which the bad IVOPT decision matters.

[Bug tree-optimization/52285] [4.7 Regression] libgcrypt _gcry_burn_stack slowdown

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52285

--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-02-16 
22:20:31 UTC ---
Author: jakub
Date: Thu Feb 16 22:20:27 2012
New Revision: 184317

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184317
Log:
PR tree-optimization/52285
* tree-tailcall.c (find_tail_calls): Ignore gimple_clobber_p stmts
when deciding if a call is a tail call or tail recursion.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-tailcall.c