Re: *_BY_PIECES_P flaw

["H. J. Lu" <hjl at lucon dot org>]

On Thu, Aug 05, 2004 at 09:47:18AM -0400, Jakub Jelinek wrote:
> 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?

While you are on that, could you please also take a look at

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13144

They are related.

Thanks.


H.J.