------- Additional Comments From macro at linux-mips dot org 2005-08-09 11:38
-------
Thanks for your insight. I did some experimenting with the code (including
reducing the source file to a somewhat more readable form -- I can post it
if interested) and I noticed this *(struct { char __x[0xfffffff]; } *) cast
is somehow involved. I searched the info pages to find out what exactly it
is expected to mean to GCC, but I failed. Anyway I sense this effectively
tells all the memory (0xfffffff is close to 1/16 of the target's address
space) is potentially to be referred to, forcing any variables cached in
registers to be written back to their corresponding memory locations. Am I
right?
But "__d3" is a temporary and if located on the stack, it's not going to
affect "__s" in a well-defined program. Is there a way to tell GCC about
that?
Of course it can be worked around by using "=m" as the constraint for
"__d3", but then the opportunity to use a register when one is actually
available is lost. I've tried to use alternative constraints with an early
clobber for the register variation only (i.e. "=&r,m"), but GCC still
insisted on using a register.
BTW, thanks for the hint about calling strcspn() -- I've noticed the
problem disappears when one of these calls is removed, too. I'll prepare a
patch for glibc as a microoptimization here. But of course <bits/string.h>
is a user header, so we cannot simply cover the problem by changing
md5-crypt.c and praying it won't reappear elsewhere. ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22045
