From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5706 invoked by alias); 17 Jun 2011 12:26:21 -0000 Received: (qmail 5695 invoked by uid 22791); 17 Jun 2011 12:26:19 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_TQ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 17 Jun 2011 12:26:03 +0000 Received: (qmail 8320 invoked from network); 17 Jun 2011 12:26:02 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 Jun 2011 12:26:02 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.72) (envelope-from ) id 1QXY7c-0004Rd-LA; Fri, 17 Jun 2011 12:26:00 +0000 Date: Fri, 17 Jun 2011 13:06:00 -0000 From: "Joseph S. Myers" To: Georg-Johann Lay cc: gcc-patches@gcc.gnu.org, Denis Chertykov , Anatoly Sokolov , "Eric B. Weddington" Subject: Re: [Patch, AVR]: QI builtins for parity, popcount, 1<< n In-Reply-To: <4DFB32BA.9090009@gjlay.de> Message-ID: References: <4DFA26FE.1000400@gjlay.de> <4DFB32BA.9090009@gjlay.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg01336.txt.bz2 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__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__add to generate that instruction but rather to make '+' generate it. -- Joseph S. Myers joseph@codesourcery.com