From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28807 invoked by alias); 17 Aug 2012 18:57:37 -0000 Received: (qmail 28798 invoked by uid 22791); 17 Aug 2012 18:57:36 -0000 X-SWARE-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 17 Aug 2012 18:57:23 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1T2RjV-0000FV-JV from Andrew_Stubbs@mentor.com ; Fri, 17 Aug 2012 11:57:21 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Aug 2012 11:57:21 -0700 Received: from [172.30.6.68] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Fri, 17 Aug 2012 19:57:19 +0100 Message-ID: <502E940C.2000902@codesourcery.com> Date: Fri, 17 Aug 2012 18:57:00 -0000 From: Andrew Stubbs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Richard Earnshaw CC: "gcc-patches@gcc.gnu.org" , Richard Sandiford Subject: Re: [patch, tree-ssa] PR54295 Incorrect value extension in widening multiply-accumulate References: <502E4F54.9040309@arm.com> <502E53A7.406@codesourcery.com> <502E55CE.6020304@arm.com> <502E57A9.8050502@codesourcery.com> <502E598F.9010105@arm.com> <502E5DE6.8090806@codesourcery.com> <502E612E.60706@arm.com> In-Reply-To: <502E612E.60706@arm.com> Content-Type: text/plain; charset="windows-1252"; 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: 2012-08/txt/msg01203.txt.bz2 On 17/08/12 16:20, Richard Earnshaw wrote: >> No, given a u16xu16->u64 operation in the code, and that the arch >> doesn't have such an opcode, I'd expect to get >> >> step1 -> (u32)u16 x (u32)u16 -> u64 > > Hmm, I would have thought that would be more costly than > > (u64)(u16 x u16 -> u32) You might be right, but then extends are often free, especially with unsigned types, so it's hard to say for sure. Did you reproduce one? It's a long time since I last looked at this stuff, so I could be confused. Andrew