From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Georg-Johann Lay <avr@gjlay.de>
Cc: gcc-patches@gcc.gnu.org, Denis Chertykov <chertykov@gmail.com>,
Anatoly Sokolov <aesok@post.ru>,
"Eric B. Weddington" <eric.weddington@atmel.com>
Subject: Re: [Patch, AVR]: QI builtins for parity, popcount, 1<< n
Date: Fri, 17 Jun 2011 13:06:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1106171213510.16331@digraph.polyomino.org.uk> (raw)
In-Reply-To: <4DFB32BA.9090009@gjlay.de>
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.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2011-06-17 12:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-16 16:08 Georg-Johann Lay
2011-06-16 17:08 ` Joseph S. Myers
2011-06-17 11:04 ` Georg-Johann Lay
2011-06-17 13:06 ` Joseph S. Myers [this message]
2011-06-17 19:03 ` Georg-Johann Lay
2011-06-17 19:14 ` Georg-Johann Lay
2011-06-20 10:53 ` Joseph S. Myers
2011-06-20 14:31 ` Georg-Johann Lay
2011-06-20 15:39 ` Richard Henderson
2011-06-20 16:52 ` Georg-Johann Lay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1106171213510.16331@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=aesok@post.ru \
--cc=avr@gjlay.de \
--cc=chertykov@gmail.com \
--cc=eric.weddington@atmel.com \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).