This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Commit: XStormy16: Add __clrsbhi2() to libgcc
- From: Georg-Johann Lay <avr at gjlay dot de>
- To: nick clifton <nickc at redhat dot com>
- Cc: Georg-Johann Lay <gjl at gcc dot gnu dot org>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 02 Aug 2012 17:10:57 +0200
- Subject: Re: Commit: XStormy16: Add __clrsbhi2() to libgcc
- References: <87y5m0uzks.fsf@redhat.com> <50184CB4.4010509@gcc.gnu.org> <5018F6A7.2080306@redhat.com>
nick clifton wrote:
> Hi Johann,
>> Hi, just out of curiosity: Is there a special reason to add a
>> stormy16-specific implementation instead of using the code in
>> libgcc2.c? t-avr for example uses the C implementation in libgcc2.c
>> for HI. Are there disadvantages?
>
> Apart from not using some slightly frightening makefile magic ? No, no
> real reason. In fact the implementation in stormy16/lib2funcs.c is
> based directly on the code in libgcc2.c.
>
> I prefer my current approach because if it turns out that this function
> is used a lot then it will easy to replace the current C implementation
> with hand coded assembler. But if there was a way to automate the
> detection of bit counting functions in libgcc2.c, so that when a new one
> is added we would not have to update t-avr or t-stormy16, then I would
> go with your approach.
Yes, I agree. It would be great if the needed HI-mode built-ins were
generated automatically for the 16-bit int targets; without explicit
interaction or dreaded makefile code.
The avr mainly needs these build-ins to reduce testsuite noise
if these built-ins are missing.
Johann
>
> Cheers
> Nick