This is the mail archive of the 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

> 2003-04-11  Kaveh R. Ghazi  <ghazi at caip dot rutgers dot edu>
> gcc:
> 	* builtins.c (expand_builtin_memcpy): Add `endp' argument, use it.
> 	(expand_builtin_stpcpy): New.
> 	(expand_builtin): Add BUILT_IN_MEMPCPY & BUILT_IN_STPCPY.
> 	* builtins.def: Add mempcpy & stpcpy support.
> 	* doc/extend.texi (mempcpy, stpcpy): Document builtin.

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);
char *bar (char *a, size_t len)
  return stpcpy (a, "foobarbaz" + len);

at -O2 will essentially result in:
size_t tmp = ++c;
return memcpy (a, b, tmp) + tmp;
return memcpy (a, "foobarbaz" + len, 10 - len) + (10 - len) - 1;
(in both cases it increases unnecessarily register preasure,
calls some function as well and generates extra instructions which would
not be needed when not doing the optimization at all.

IMHO expand_builtin_stpcpy needs to check for c_getstr () != NULL instead
of c_strlen () != NULL. 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.


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