[AVR] : QI builtins for parity, popcount, 1<< n

The recent implementation of some asm function in libgcc added
__popcountqi2 and __parityqi2. This patch makes these functions
available as __builtin_avr_popcount8 resp. __builtin_avr_parity8.

Moreover, just out of a mood, I wrote a builtin for 1<<n.
1<<n is sometimes used to set a variable SFR bit. The builtin supplies
a fast, loop-free implementation.

The nice thing is that all these can represented explicitly so that
gcc sees what's going on and can fold if it sees operation on a
compile time constant.

Johann

	* config/avr/avr.c (avr_init_builtins, avr_builtin_id,
	bdesc_1arg): Add support for __builtin_avr_parity8,
	__builtin_avr_popcount8, __builtin_avr_pow2.
	(adjust_insn_length): Filter out "ashlqi2_1" insn in length
	computation.
	* config/avr/avr.c (avr_cpu_cpp_builtins): New builtin defines for
	__BUILTIN_AVR_PARITY8, __BUILTIN_AVR_POPCOUNT8,	__BUILTIN_AVR_POW2.
	* config/avr/avr.md (parityqi2): New expander.
	(popcountqi2): New expander.
	(*parityqihi2.libgcc): New insn.
	(*popcountqi2.libgcc): New insn.
	(ashlqi2_1): New insn.
	* doc/extend.texi (AVR Built-in Functions): Document new builtins
	__builtin_avr_parity8, __builtin_avr_popcount8,
	__builtin_avr_pow2.

On Thu, 16 Jun 2011, Georg-Johann Lay wrote:

> The recent implementation of some asm function in libgcc added
> __popcountqi2 and __parityqi2. This patch makes these functions
> available as __builtin_avr_popcount8 resp. __builtin_avr_parity8.
> 
> Moreover, just out of a mood, I wrote a builtin for 1<<n.
> 1<<n is sometimes used to set a variable SFR bit. The builtin supplies
> a fast, loop-free implementation.

I hope this whole patch is just intended as an example of how to add 
built-in functions and not as a serious proposal for an addition to GCC, 
since it doesn't make sense to add machine-specific built-in functions for 
things that can so readily be represented in generic GNU C; instead, you 
should make generic GNU C generate the right code (for example, by 
handling __builtin_parity and __builtin_popcount smartly on zero-extended 
values if QImode patterns are available - if it doesn't already do so).

Joseph S. Myers schrieb:
> On Thu, 16 Jun 2011, Georg-Johann Lay wrote:
> 
>> The recent implementation of some asm function in libgcc added
>> __popcountqi2 and __parityqi2. This patch makes these functions
>> available as __builtin_avr_popcount8 resp. __builtin_avr_parity8.
>>
>> Moreover, just out of a mood, I wrote a builtin for 1<<n.
>> 1<<n is sometimes used to set a variable SFR bit. The builtin supplies
>> a fast, loop-free implementation.
> 
> I hope this whole patch is just intended as an example of how to add 
> built-in functions and not as a serious proposal for an addition to GCC, 
> since it doesn't make sense to add machine-specific built-in functions for 
> things that can so readily be represented in generic GNU C; instead, you 
> should make generic GNU C generate the right code (for example, by 
> handling __builtin_parity and __builtin_popcount smartly on zero-extended 
> values if QImode patterns are available - if it doesn't already do so).
> 
> Joseph S. Myers

I don't see what's bat with the patch, it's straight forward.

As I don't intend to introduce new register classes and constraints
(hard regnos won't do any more if combine is intended to come up with
new insn, what it actually does) just for that... Dropping the patch.

Johann

On Fri, 17 Jun 2011, Georg-Johann Lay wrote:

> I don't see what's bat with the patch, it's straight forward.

C is a high-level language, defined in terms of high-level semantics 
rather than machine instructions.  C code should be written where possible 
using machine-independent functionality, falling into machine-dependent 
operations only where the semantics cannot readily be represented in a 
machine-independent way; the compiler should generally be responsible for 
picking optimal instructions for the source code.

C code should write "1 << n" (or "1 << (n & 7)" if that's what it wants) 
for shifts rather than __builtin_avr_pow2.  That way it's more portable 
and more readable to general C programmers who aren't familiar with all 
the machine-specific interfaces.  Similarly, code wanting to add values 
should use the "+" operator rather than each target having its own 
__builtin_<arch>_add.  And since parity and population-count operations 
are widely present and generically useful, GNU C has generic built-in 
functions for those, so code should use __builtin_parity and 
__builtin_popcount on all machines rather than machine-specific variants; 
such machine-specific variants should not exist.

The machine-independent parts of the compiler should know about the 
equivalence of (popcount X) and (popcount (zero_extend X)), (parity X) and 
(parity (zero_extend X)) and (parity X) and (parity (sign_extend X)) if 
the sign-extension is by an even number of bits - in fact, there is 
already code in simplify_unary_operation_1 that does know this (the 
assumption that all sign-extensions are by an even number of bits is 
hardcoded).  The target should just need to describe how to code these 
operations on various modes.  If the existing code doesn't suffice to 
cause popcountqi etc. patterns to be used for the generic built-in 
functions, the appropriate fix is generic rather than adding new 
target-specific built-in functions - just as if the compiler didn't 
generate your target's addition instruction from the '+' operator, the 
right fix is not to add __builtin_<arch>_add to generate that instruction 
but rather to make '+' generate it.