This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Generated libcalls
- To: pthomas at suse dot de
- Subject: Re: Generated libcalls
- From: "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>
- Date: Wed, 1 Mar 2000 09:36:16 +0100
- CC: gcc at gcc dot gnu dot org
- References: <20000229231752.L20805@Jeffreys.suse.de> <200002292359.AAA14791@loewis.home.cs.tu-berlin.de> <20000301015901.A2065@Jeffreys.suse.de>
> But mostly because I'd rather avoid the inevitable discussion that
> would follow the proposal to add a new #pragma ;->
Indeed, so just ignore that proposal...
> The problem with this matter is, that, as Jan Hubicka pointed out to
> me, it's rather hard to implement such a switch as at that point, a
> libcall is just another function. I've never dealt with gcc on that
> level so I can't make comments about the validity of that statement.
Maybe I'm missing something, but... Currently, determination whether
to use memcpy or not is made with the line
if (GET_CODE (size) == CONST_INT && MOVE_BY_PIECES_P (INTVAL (size), align))
move_by_pieces (x, y, INTVAL (size), align);
I can't see the problem changing this to
if (GET_CODE (size) == CONST_INT
&& (flag_freestanding || MOVE_BY_PIECES_P (INTVAL (size), align)))
move_by_pieces (x, y, INTVAL (size), align);
Of course, you'll have to catch a number of other cases as well
(e.g. clear-by-pieces), and you'll have to consider the case that
there's a copy where the size is not constant. However, I guess this
does not come up out of the compiler itself, only perhaps as a result
from calling __builtin_memcpy - which you shouldn't do in a
freestanding environment.
Please let me know if you do follow this approach.
Regards,
Martin