From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9954 invoked by alias); 20 Jun 2011 10:04:29 -0000 Received: (qmail 9945 invoked by uid 22791); 20 Jun 2011 10:04:28 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,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; Mon, 20 Jun 2011 10:04:13 +0000 Received: (qmail 30258 invoked from network); 20 Jun 2011 10:04:13 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 Jun 2011 10:04:13 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.72) (envelope-from ) id 1QYbL0-00039l-RM; Mon, 20 Jun 2011 10:04:10 +0000 Date: Mon, 20 Jun 2011 10:53:00 -0000 From: "Joseph S. Myers" To: Georg-Johann Lay cc: gcc-patches@gcc.gnu.org, Denis Chertykov , Anatoly Sokolov , "Eric B. Weddington" , Richard Henderson Subject: Re: [Patch, AVR]: QI builtins for parity, popcount, 1<< n In-Reply-To: <4DFB9DD9.9070700@gjlay.de> Message-ID: References: <4DFA26FE.1000400@gjlay.de> <4DFB32BA.9090009@gjlay.de> <4DFB9DD9.9070700@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/msg01436.txt.bz2 On Fri, 17 Jun 2011, Georg-Johann Lay wrote: > So here is my question: Would it be big deal to teach optabs to expand > plus:di, minus:di as libcall? Maybe even compare is feasible? Like so: I don't know what the best approach would be, but for just about any operation supported by GCC it makes sense to support expanding it as a libcall if that's the most efficient approach for a given target. Some of the generic optabs code could probably do with having target hooks added to make it work better for the less common targets. In particular, there are hardcoded references to SImode on the basis that some libcalls only exist for SImode and wider. Those may not be optimal for 8-bit and 16-bit targets, and certainly would be bad if any targets with bytes wider than 8 bits (so SImode, which is always four bytes, wider than 32 bits) get added in future. Changing that might require changes to how libgcc is built, to build extra functions, as well as to the optabs code. (In general *any* hardcoded reference to a machine mode other than QImode is suspect and likely to need fixing for non-8-bit-byte targets as well as potentially being suboptimal for 8-bit and 16-bit targets. I don't know how many different target hooks would be needed to replace such hardcoding; that needs careful thought and a clear conceptual understanding of the purpose of each such hardcoded mode reference.) -- Joseph S. Myers joseph@codesourcery.com