This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: generic libgcc1?
- From: Maksim <maksim at mioffe dot com>
- To: Ian Lance Taylor <ian at wasabisystems dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Sun, 21 Dec 2003 13:53:32 -0500 (EST)
- Subject: Re: generic libgcc1?
Thanks a lot for the info. Is the same true of int division? What about
single precision floating ops? Are they going to be done (through a
behind-the-scenes promotion to double) in terms of the floating ops in
libgcc2 if no patterns/code is available for the single precision version?
Thanks in advance,
Maksim
On 20 Dec 2003, Ian Lance Taylor wrote:
> Maksim <maksim@mioffe.com> writes:
>
> > Is it the case that all of libgcc1 _has_ to be implemented by the
> > target-specific part of the backend? Isn't it possible to implement a lot
> > of it in C, just as it's done with libgcc2? (i.e., implement mulsi3 in terms
> > of addsi3 and so on) I feel like I'm missing something.
>
> You can implement mulsi3 in terms of addsi3, but you do have to do it
> either in the RTL or in libgcc1. gcc won't do it for you. You must
> either have a mulsi3 pattern or you must have a __mulsi3 function.
>
> Well, that isn't 100% true, since I think gcc will implement mulsi3 in
> terms of muldi3 if the latter is available. But gcc won't implement
> mulsi3 in terms of addsi3.
>
> This is probably because a __mulsi3 written in hand-coded assembler
> will normally be better than whatever gcc comes up with. But if you
> really think it would be useful to implement mulsi3 in terms of
> addsi3, then the place to add the code would be expand_binop() in
> optabs.c.
>
> Ian
>