From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47326 invoked by alias); 17 Dec 2015 17:44:25 -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 47316 invoked by uid 89); 17 Dec 2015 17:44:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*u:31.2.0, H*UA:31.2.0, !in_compare, IN_COMPARE X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 Dec 2015 17:44:23 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 641BF491; Thu, 17 Dec 2015 09:43:57 -0800 (PST) Received: from [10.2.206.200] (e100706-lin.cambridge.arm.com [10.2.206.200]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 88D6A3F21A; Thu, 17 Dec 2015 09:44:21 -0800 (PST) Message-ID: <5672F474.5070306@foss.arm.com> Date: Thu, 17 Dec 2015 17:44:00 -0000 From: Kyrill Tkachov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Segher Boessenkool , Bernd Schmidt CC: GCC Patches Subject: Re: [PATCH][combine][RFC][2/2] PR rtl-optimization/68796: Perfer zero_extract comparison against zero rather than unsupported shorter modes References: <5672D68F.3030408@foss.arm.com> <5672DB97.7090800@redhat.com> <5672DE74.7080802@foss.arm.com> <5672DEE0.8000509@redhat.com> <20151217172732.GA20301@gate.crashing.org> In-Reply-To: <20151217172732.GA20301@gate.crashing.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-12/txt/msg01802.txt.bz2 On 17/12/15 17:27, Segher Boessenkool wrote: > On Thu, Dec 17, 2015 at 05:12:16PM +0100, Bernd Schmidt wrote: >> On 12/17/2015 05:10 PM, Kyrill Tkachov wrote: >>> Well, this patch still produces the QImode comparison if the target has >>> a QImode comparison >>> (the have_insn_for check in the simplify_comparison hunk). >> Ok, I didn't look that closely because I had doubts about the approach. >> This kind of check also goes somewhat against the principles of just >> producing canonical forms of RTL. > The canonicalisation rules exist so that optimisers only need to match > one form instead of several, and machine descriptions only need to > describe one form instead of several. For this bitmasking case it > perversely forces you to describe the same instruction in many ways, > for many targets. This is what the change_zero_ext was about as well. > > It's not so easy to fix for the compare case. Maybe the idea of making > genrecog make code that recognises more forms of the same insn will work > out. GCC 7 in any case... Perhaps I had underestimated how involved this issue is :) So if I want to improve the aarch64 situation for GCC 6, would the recommended course of action be to just define the QI and HImode compare against zero patterns? Note that I think the make_extraction hunk from my patch is in line with the function comment of make_extraction that says: " IN_COMPARE is nonzero if we are in a COMPARE. This means that a ZERO_EXTRACT should be built even for bits starting at bit 0." whereas the condition that I'm adding "&& !in_compare" is explicitly trying to avoid an extraction. But anyway, if this has the potential to cause negative fallout that I had not anticipated, it can wait for later. Thanks, Kyrill > > Segher