[Bug tree-optimization/52285] [4.7 Regression] libgcrypt _gcry_burn_stack slowdown
jakub at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Mon Feb 20 11:20:00 GMT 2012
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?
More information about the Gcc-bugs
mailing list