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

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot 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?