Commit: XStormy16: Add __clrsbhi2() to libgcc

Hi Guys,

  I am checking in the patch below to add a __clrsbhi2 function to
  libgcc for the XStormy16 port.  This fixes several gcc testsuite
  failures that need this particular function.

Cheers
  Nick

libgcc/ChangeLog
2012-07-31  Nick Clifton  <nickc@redhat.com>

	* config/stormy16/lib2funcs.c (__clrsbhi2): New function.
	Implements __clrsb for an HImode argument.
	* config/stormy16/clrsbhi2.c: New file:
	* config/stormy16/t-stormy16 (LIB2ADD): Add clrsbhi2.c.

Nick Clifton schrieb:
> Hi Guys,
> 
>   I am checking in the patch below to add a __clrsbhi2 function to
>   libgcc for the XStormy16 port.  This fixes several gcc testsuite
>   failures that need this particular function.
> 
> Cheers
>   Nick

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?

Johann

> libgcc/ChangeLog
> 2012-07-31  Nick Clifton  <nickc@redhat.com>
> 
> 	* config/stormy16/lib2funcs.c (__clrsbhi2): New function.
> 	Implements __clrsb for an HImode argument.
> 	* config/stormy16/clrsbhi2.c: New file:
> 	* config/stormy16/t-stormy16 (LIB2ADD): Add clrsbhi2.c.
> 
> Index: libgcc/config/stormy16/clrsbhi2.c
> ===================================================================
> --- libgcc/config/stormy16/clrsbhi2.c	(revision 0)
> +++ libgcc/config/stormy16/clrsbhi2.c	(working copy)
> @@ -0,0 +1,2 @@
> +#define XSTORMY16_CLRSBHI2
> +#include "lib2funcs.c"
> Index: libgcc/config/stormy16/t-stormy16
> ===================================================================
> --- libgcc/config/stormy16/t-stormy16	(revision 189996)
> +++ libgcc/config/stormy16/t-stormy16	(working copy)
> @@ -33,6 +33,7 @@
>  	$(srcdir)/config/stormy16/clzhi2.c \
>  	$(srcdir)/config/stormy16/ctzhi2.c \
>  	$(srcdir)/config/stormy16/ffshi2.c \
> +	$(srcdir)/config/stormy16/clrsbhi2.c \
>  	$(srcdir)/config/stormy16/cmpsi2.c \
>  	$(srcdir)/config/stormy16/ucmpsi2.c
>  
> Index: libgcc/config/stormy16/lib2funcs.c
> ===================================================================
> --- libgcc/config/stormy16/lib2funcs.c	(revision 189996)
> +++ libgcc/config/stormy16/lib2funcs.c	(working copy)
> @@ -311,6 +311,22 @@
>  }
>  #endif
>  
> +#ifdef XSTORMY16_CLRSBHI2
> +/* Returns the number of leading redundant sign bits in X.
> +   I.e. the number of bits following the most significant bit which are
> +   identical to it.  There are no special cases for 0 or other values.  */
> +
> +int
> +__clrsbhi2 (HWtype x)
> +{
> +  if (x < 0)
> +    x = ~x;
> +  if (x == 0)
> +    return 15;
> +  return __builtin_clz (x) - 1;
> +}
> +#endif
> +
>  #ifdef XSTORMY16_UCMPSI2
>  /* Performs an unsigned comparison of two 32-bit values: A and B.
>     If A is less than B, then 0 is returned.  If A is greater than B,
>

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.

Cheers
   Nick

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