This is the mail archive of the
mailing list for the GCC project.
Re: Patch to add builtin mempcpy and stpcpy
- From: Jakub Jelinek <jakub at redhat dot com>
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sun, 4 May 2003 15:55:58 -0400
- Subject: Re: Patch to add builtin mempcpy and stpcpy
- References: <200304120341.XAA15220@caip.rutgers.edu> <20030428173746.S13397@devserv.devel.redhat.com> <200305041850.OAA12228@caip.rutgers.edu>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Sun, May 04, 2003 at 02:50:23PM -0400, Kaveh R. Ghazi wrote:
> Jakub - sorry for the delay,
> 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?
Well, what I meant is for mempcpy/stpcpy to be really good optimization
current emit_block_move is inappropriate. I believe in all 3 variants of
the move (move_by_pieces, movstr and store_by_pieces) which are suitable
for mempcpy/stpcpy the end address (ie. what mempcpy returns, for stpcpy
it would still need to be decremented) is in some pseudo after the
operation. So best would be to return this instead of computing the end
address by adding len to the start address (and it could decrease
register preasure as well).
It is certainly more work then just disallowing move by libcall in
emit_block_move called from mempcpy builtin, but I seriously doubt the
optimizers can figure this out.