From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115696 invoked by alias); 4 Mar 2015 12:49:13 -0000 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 Received: (qmail 115672 invoked by uid 89); 4 Mar 2015 12:49:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lb0-f171.google.com Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com) (209.85.217.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 04 Mar 2015 12:49:11 +0000 Received: by lbjb6 with SMTP id b6so8768425lbj.9 for ; Wed, 04 Mar 2015 04:49:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=OQvun1tPzHTrmMOgkegIQ4w82fYJjtln7ViqFFOon/w=; b=O3HLmjYdqEulJCykiCmq2taBgTMD+kaIPYyNMeWTZnHqlD2QqGh49Y+qQrhByWlqOF XhHc/+oG6PKNSqnekPOixsAQGsGBmhzUqdOU6MhR7gT4DIRW5BZ8b4Ej52TUORtAf3XO eVHrOpIz+TXGbZTsRyDeg+xZPKdUvdreH4cu2Juv+q96xAmuBsTH8ilkkLvwBKzTiXkg td4CNU58+y0VDvoCvSFBp/IQ/U3GFN0GcGWqyjCDjC2nkWCmGr7QK6Mx9h8+nYkTnUK2 P+RU1t3aFourfwwgP+f2KiN06mV1/qUJxDlKWhSRUiMGrH8BTDhYMGTi4pnv42xGq/wQ +m2g== X-Gm-Message-State: ALoCoQmKCFyQC1HTaUsvfRvedvm3KeadllroDhXT5dY4q8Cii1F+2ycpPtO+larbHSFP1jW7HOBj X-Received: by 10.112.12.134 with SMTP id y6mr3357605lbb.34.1425473348339; Wed, 04 Mar 2015 04:49:08 -0800 (PST) Received: from [192.168.1.118] ([90.154.65.7]) by mx.google.com with ESMTPSA id nx1sm746571lbb.27.2015.03.04.04.49.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Mar 2015 04:49:07 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: [PATCH][AArch64] Use conditional negate for abs expansion From: Maxim Kuvyrkov In-Reply-To: <000101d05677$0f973890$2ec5a9b0$@com> Date: Wed, 04 Mar 2015 12:49:00 -0000 Cc: GCC Patches Content-Transfer-Encoding: quoted-printable Message-Id: References: <000901d055cd$ce6ed110$6b4c7330$@com> <000101d05677$0f973890$2ec5a9b0$@com> To: Wilco Dijkstra X-SW-Source: 2015-03/txt/msg00207.txt.bz2 > On Mar 4, 2015, at 3:30 PM, Wilco Dijkstra wrote: >=20 >> Maxim Kuvyrkov wrote: >>=20 >> You are removing the 2nd alternative that generates "abs" with your patc= h. While I agree that >> using "csneg" is faster on all implementations, can you say the same for= "abs"? Especially >> given the fact that csneg requires 4 operands instead of abs'es 2? >=20 > Yes, given that latencies of scalar SIMD instructions are typically worse= than integer > latencies. The number of operands is not an issue. One could make an argument that having an opportunity to use FP registers i= n high-reg-pressure code is valuable. But ... I can take your word for it.= All-in-all, I don't have objections to your patch (note, this is a review= , not approval, since I'm not an ARM maintainer). >=20 >> Wouldn't it be better to have (define_expand "abs2") that would ex= pand into either >> csneg3 or second alternative of current absdi2? >=20 > How would that be possible? You'd have to delay expansion until after reg= ister allocation, > which loses optimization opportunities. If abs2 define_expand is given arguments in DI mode that are FP regis= ter -- emit absdi2_insn. Otherwise (which will be 95% of the time) do what= your patch does. > And I still don't see how it would ever make sense=20 > to execute integer operations as scalar SIMD. >=20 Many GCC ports exploit ability to use FP registers for storage of integer v= alues for the benefit of high-reg-pressure code. Ability to do some basic = operations (like abs) on such integer values is beneficial for the same rea= son. However, almost always FP-alternatives are not the only ones in the instruc= tion pattern, and they are discouraged with "!". If you can't use "!" to d= iscourage them (which you can't in a single-alternative case, like we got h= ere) then your approach makes sense. [Yes, I know, you could fit that FP a= lternative into csneg pattern, but, probably, you would not want to spend y= our time on it, and I don't think it's important enough to ask you to.] Thanks, -- Maxim Kuvyrkov www.linaro.org