This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [gfortran,patch] Don't call library function for string copying, take 2
- From: "THOMAS Paul Richard 169137" <Paul dot Richard dot THOMAS at cea dot fr>
- To: "Jakub Jelinek" <jakub at redhat dot com>
- Cc: "FX Coudert" <fxcoudert at gmail dot com>, <gcc-patches at gcc dot gnu dot org>, <fortran at gcc dot gnu dot org>
- Date: Tue, 11 Jul 2006 13:05:51 +0200
- Subject: RE: [gfortran,patch] Don't call library function for string copying, take 2
Jakub,
Thanks for the remark - I had meant to ask whether or not the middle
end would inline these functions or not.
>
> GCC knows about the memcpy/memmove builtins and optimizes them where
> possible/desirable. If that is not working well, you should
> try to improve
> the memcpy/memmove builtin optimizations in the middle-end rather than
> open code memmove or memcpy on your own.
OK - thanks
>
> All that the Fortran FE could do is if it can prove that the
> memories don't
> overlap AND the proof of this is something that Fortran
> specific and lost
> after the conversion to GIMPLE, then the FE should insert
> memcpy builtin
> rather than memmove and let builtins.c do its job.
>
That is easily done but I wonder how much that it would gain?
Paul