This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
*_BY_PIECES_P flaw
- From: Jakub Jelinek <jakub at redhat dot com>
- To: gcc at gcc dot gnu dot org
- Date: Thu, 5 Aug 2004 09:47:18 -0400
- Subject: *_BY_PIECES_P flaw
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
Hi!
MOVE_BY_PIECES_P, CLEAR_BY_PIECES_P and STORE_BY_PIECES_P macros
use by default move_by_pieces_ninsns routine. Unfortunately it computes
things which are IMHO completely unrelated to what is needed.
The problem is that move_by_pieces uses at most MOVE_MAX_PIECES
bytes large mode to perform the moving, store_by_pieces and clear_by_pieces
uses at most STORE_MAX_PIECES big mode. But move_by_pieces_ninsns
uses at most MOVE_MAX bytes large mode. So if these constants are smaller
than MOVE_MAX (as e.g. on IA-32, MOVE_MAX is 16 while MOVE_MAX_PIECES
== STORE_MAX_PIECES is sizeof (long)), there are surprising results.
E.g. if a block of memory is to be cleared and is 16 bytes aligned with -m64,
move_by_pieces_nisnsns tells us it is 1 instruction, but the clearing
will be done with two DImode stores. But if it is just 8 bytes aligned,
move_by_pieces_nisnsns will return 2 and with the default CLEAR_RATIO
2 (which is IMHO too low for IA-32), suddenly clear_by_pieces will not
be used, although exactly the same instructions would be generated.
I think best would be to add a max_size argument to this function,
which would be MOVE_MAX_PIECES + 1 or STORE_MAX_PIECES + 1 depending
on in which macro or routine it is used.
Such change would need perhaps some corrections to i386, x86_64 and SH
MOVE_RATIO/CLEAR_RATIO/MOVE_BY_PIECES_P settings.
What do you think?
Jakub