From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31081 invoked by alias); 28 Jun 2011 16:15:00 -0000 Received: (qmail 31066 invoked by uid 22791); 28 Jun 2011 16:14:57 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Jun 2011 16:14:41 +0000 Received: by wwi14 with SMTP id 14so3065372wwi.2 for ; Tue, 28 Jun 2011 09:14:40 -0700 (PDT) Received: by 10.227.32.69 with SMTP id b5mr6744295wbd.99.1309277680187; Tue, 28 Jun 2011 09:14:40 -0700 (PDT) Received: from [192.168.0.100] (cpc2-hawk4-0-0-cust828.aztw.cable.virginmedia.com [82.32.123.61]) by mx.google.com with ESMTPS id o19sm270538wbh.4.2011.06.28.09.14.37 (version=SSLv3 cipher=OTHER); Tue, 28 Jun 2011 09:14:38 -0700 (PDT) Message-ID: <4E09FDEA.3000004@gmail.com> Date: Tue, 28 Jun 2011 16:48:00 -0000 From: Andrew Stubbs User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Michael Matz CC: Richard Guenther , gcc-patches@gcc.gnu.org, patches@linaro.org Subject: Re: [PATCH (3/7)] Widening multiply-and-accumulate pattern matching References: <4E034EF2.3070503@codesourcery.com> <4E03504B.9060305@codesourcery.com> <4E044559.5000105@linaro.org> <1A77B5B39081C241A68E6CF16983025F020906F6@EU1-MAIL.mgc.mentorg.com> <4E09B142.4020402@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg02153.txt.bz2 On 28/06/11 16:53, Michael Matz wrote: > On Tue, 28 Jun 2011, Richard Guenther wrote: >> I'd name the predicate value_preserving_conversion_p which I think is >> what you mean. harmless isn't really descriptive. >> >> Note that you include non-value-preserving conversions, namely int -> >> unsigned int. > > It seems that Andrew really does want to accept them. If so > value_preserving_conversion_p would be the wrong name. It seems to me he > wants to accept those conversions that make it possible to retrieve the > old value, i.e. when "T1 x; (T1)(T2)x == x", then T1->T2 has the > to-be-named property. bits_preserving? Hmm. What I want (and I'm not totally clear on what this actually means) is to be able to optimize all the cases where the end result will be the same as the compiler produces now (using multiple multiply, shift, and add operations). Ok, so that's an obvious statement, but the point is that, right now, the compiler does nothing special when you cast from int -> unsigned int, or vice-versa, and I want to capture that somehow. There are some exceptions, I'm sure, but what are they? What is clear is that I don't want to just assume that casting from one signedness to the other is a show-stopper. For example: unsigned long long foo (unsigned long long a, unsigned char b, unsigned char c) { return a + b * c; } This appears to be entirely unsigned maths with plenty of spare precision, and therefore a dead cert for any SI->DI multiply-and-accumulate instruction, but not so - it is represented internally as: signed int tmp = (signed int)a * (signed int)b; unsigned long long result = a + (unsigned long long)tmp; Notice the unexpected signed int in the middle! I need to be able to get past that to optimize this properly. I've tried various test cases in which I cast signedness and mode around a bit, and so far it appear to perform safely, but probably I'm not be cunning enough. Andrew