This is the mail archive of the gcc-patches@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]

Re: Patch to add builtin mempcpy and stpcpy


 > From: Jakub Jelinek <jakub@redhat.com>
 > 
 > This seems to pessimize code in some cases:
 > 
 > typedef __SIZE_TYPE__ size_t;
 > void *foo (void *a, const void *b, size_t c)
 > {
 >   return mempcpy (a, b, ++c);
 > }
 > 
 > at -O2 will essentially result in:
 > size_t tmp = ++c;
 > return memcpy (a, b, tmp) + tmp;
 > 
 > In the expand_builtin_mempcpy it is more
 > questionable. If it is going to be expanded using store_by_pieces, it
 > is probably a win, similarly for move_by_pieces, emit_block_move_via_movstr
 > is already questionable (could be a win if we could somehow tell the movstr
 > pattern to tell us which register will contain the final address),
 > emit_block_move_via_libcall is certainly wrong and emit_block_move_via_loop
 > is likely wrong.
 > 	Jakub

Jakub - sorry for the delay, 
http://gcc.gnu.org/ml/gcc-patches/2003-04/msg02122.html

to follow up on the mempcpy part of your reply, I didn't quite
understand why *move_via_movstr is a questionable opt.  Would you
please expound on that one a bit more?

Regarding *move_via_libcall & *move_via_loop, I agree these aren't
appropriate expansions for mempcpy.  A minor nit, in reading through
emit_block_move, it seems to me that *move_via_loop will never be done
when called from the builtin since may_use_call would be true.

IMHO, the problem here is that emit_block_move is written such that it
must always provide some mechanism to perform the "move".  This is
appropriate when called from parts of the compiler which want to
generate an internal "move" operation.  But it's not necessary, in
fact it hurts us, when we're simply looking for optimizations to
perform.  If we added a parameter flag (must_expand? or something)
which is checked just before move_via_libcall or move_via_loop then we
could punt from a particular builtin's standpoint, but continue in
other cases.

If that sounds ok, I'll work on a patch.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu


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