This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] libffi-MIPS: More n64 fixes.
- From: Richard Sandiford <rsandifo at nildram dot co dot uk>
- To: David Daney <ddaney at avtrex dot com>
- Cc: Java Patch List <java-patches at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 07 Dec 2007 10:31:53 +0000
- Subject: Re: [Patch] libffi-MIPS: More n64 fixes.
- References: <4758FDF1.50909@avtrex.com>
David Daney <ddaney@avtrex.com> writes:
> As with my patch from yesterday, this patch fixes several failures in
> the libffi testsuite caused by the use of a 32 bit add instruction on a
> 64 bit pointer value causing the upper 32 bits to be clobbered. At the
> same time I took the liberty of converting several 'add a,b,0' to 'move
> a,b'. Although these were not causing any immediate problems, I think
> it makes the code more understandable.
Agreed. It also saves worrying about whether the value we're moving
is really a 32-bit one. However, I couldn't help noticing that all
the moves could be folded into neighbouring instructions. E.g.:
REG_L t4, 3*FFI_SIZEOF_ARG($fp) # load the flags word
move t6, t4 # and copy it into t6
and t4, ((1<<FFI_FLAG_BITS)-1)
simplifies to:
REG_L t6, 3*FFI_SIZEOF_ARG($fp) # load the flags word
and t4, t6, ((1<<FFI_FLAG_BITS)-1)
while things like:
move t4, t6
SRL t4, 1*FFI_FLAG_BITS
simplify to:
SRL t4, t6, 1*FFI_FLAG_BITS
As well as being more efficient, it seems slightly more readable
(at least to me).
OK with that change, thanks.
Richard