This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

*_BY_PIECES_P flaw


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]