From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87891 invoked by alias); 9 Aug 2018 05:48:50 -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 87844 invoked by uid 89); 9 Aug 2018 05:48:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=terrible, Sandiford, sandiford, Hx-languages-length:2415 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 09 Aug 2018 05:48:48 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 133393084026; Thu, 9 Aug 2018 05:48:47 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-6.rdu2.redhat.com [10.10.112.6]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0B99560BE1; Thu, 9 Aug 2018 05:48:43 +0000 (UTC) Subject: Re: [RFC][PATCH][mid-end] Optimize immediate choice in comparisons. To: Vlad Lazar , "gcc-patches@gcc.gnu.org" , nd , ian@airs.com, rguenther@suse.de, richard.sandiford@arm.com References: <87o9ee2az4.fsf@arm.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: Date: Thu, 09 Aug 2018 05:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <87o9ee2az4.fsf@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00610.txt.bz2 On 08/07/2018 02:11 PM, Richard Sandiford wrote: > Hi Vlad, > > Thanks for the patch. > > Vlad Lazar writes: >> Hi. >> >> This patch optimises the choice of immediates in integer comparisons. Integer >> comparisons allow for different choices (e.g. a > b is equivalent to a >= b+1) >> and there are cases where an incremented/decremented immediate can be loaded into a >> register in fewer instructions. The cases are as follows: >> >> i) a > b or a >= b + 1 >> ii) a <= b or a < b + 1 >> iii) a >= b or a > b - 1 >> iv) a < b or a <= b - 1 >> >> For each comparison we check whether the equivalent can be performed in less instructions. >> This is done on a statement by statement basis, right before the GIMPLE statement is expanded >> to RTL. Therefore, it requires a correct implementation of the TARGET_INSN_COST hook. >> The change is general and it applies to any integer comparison, regardless of types or location. >> >> For example, on AArch64 for the following code: >> >> int foo (int x) >> { >> return x > 0xfefffffe; >> } >> >> it generates: >> >> mov w1, -16777217 >> cmp w0, w1 >> cset w0, cs >> >> instead of: >> >> mov w1, 65534 >> movk w1, 0xfeff, lsl 16 >> cmp w0, w1 >> cset w0, hi >> >> Bootstrapped and regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu and there are no regressions. > > Looks like a useful feature. I'm playing devil's advocate to some > extent here, but did you consider instead doing this during the > expansion functions themselves? In some ways that feels more > natural because we're already operating on rtxes at that point. > It also has the advantage that it would trap comparisons that didn't > exist at the gimple level, such as when computing the carry for a > doubleword add/sub. I've got no strong opinions on doing it in cfgexpand vs the expansion functions themselves. I'm happy to have you setting overall direction here Richard. I do worry about the amount of RTL we generate and throw away during cost computation. Though it's just for comparisons, so it may not be terrible. I wouldn't be surprised if ports aren't particularly accurate in their costing computations for this kind of use -- but that's nothing new. We run into it every time we use rtx costing in a new place. I'm comfortable having targets fault in improvements for this kind of use. Jeff