From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21568 invoked by alias); 25 May 2011 13:48:28 -0000 Received: (qmail 21555 invoked by uid 22791); 25 May 2011 13:48:26 -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; Wed, 25 May 2011 13:47:59 +0000 Received: (qmail 27821 invoked from network); 25 May 2011 13:47:58 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 May 2011 13:47:58 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.72) (envelope-from ) id 1QPERJ-0000uH-Dg; Wed, 25 May 2011 13:47:57 +0000 Date: Wed, 25 May 2011 14:27:00 -0000 From: "Joseph S. Myers" To: Andrew Stubbs cc: Bernd Schmidt , Richard Earnshaw , gcc-patches@gcc.gnu.org Subject: Re: [patch][simplify-rtx] Fix 16-bit -> 64-bit multiply and accumulate In-Reply-To: <4DDD065C.4020502@codesourcery.com> Message-ID: References: <4D01018F.3020108@codesourcery.com> <1296153619.9738.16.camel@e102346-lin.cambridge.arm.com> <4D42955C.1060707@codesourcery.com> <1296223929.9738.30.camel@e102346-lin.cambridge.arm.com> <4D42DD32.7020404@codesourcery.com> <1296228038.9738.48.camel@e102346-lin.cambridge.arm.com> <4D8CC0A9.5080504@codesourcery.com> <4DA823F1.2040907@codesourcery.com> <4DBFC5D8.1090009@codesourcery.com> <4DDBE035.8050901@codesourcery.com> <4DDCF7A7.4000200@codesourcery.com> <4DDD065C.4020502@codesourcery.com> 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-05/txt/msg01851.txt.bz2 On Wed, 25 May 2011, Andrew Stubbs wrote: > On 25/05/11 14:19, Joseph S. Myers wrote: > > RTL has defined abstract semantics and RTL transformations should be ones > > that are valid in accordance with those semantics, with proper assertions > > if there are additional constraints on the input passed to a function. > > This means actually counting the numbers of variable bits in the operands > > to determine whether the multiplication could overflow. > > Ok, fair enough, so how can I identify a valid subreg extraction that is > defined in terms of shifts? The shift must be by a positive constant amount, strictly less than the precision (GET_MODE_PRECISION) of the mode (of the value being shifted). If that applies, the relevant number of bits is the precision of the mode minus the number of bits of the shift. For an extension, just take the number of bits in the inner mode. Add the two numbers of bits; if the result does not exceed the number of bits in the mode (of the operands and the multiplication) then the multiplication won't overflow. As in your patch, either all the operands must be sign-extensions / arithmetic shifts (and then the result is equivalent to a widening signed multiply), or all must be zero-extensions / logical shifts (and the result is a widening unsigned multiply). -- Joseph S. Myers joseph@codesourcery.com