This is the mail archive of the gcc@gcc.gnu.org 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: 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
>


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