From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24651 invoked by alias); 26 Jun 2014 01:06:35 -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 24638 invoked by uid 89); 26 Jun 2014 01:06:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f53.google.com Received: from mail-pa0-f53.google.com (HELO mail-pa0-f53.google.com) (209.85.220.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 26 Jun 2014 01:06:32 +0000 Received: by mail-pa0-f53.google.com with SMTP id ey11so2398393pad.26 for ; Wed, 25 Jun 2014 18:06:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VtkC093IOGFSw9I/hK+BX7A9Y0s6BFvVWhUwt/OxRAM=; b=Arqk0YaJCjcm5/LUXBmCvlyPd2F5o9Aznd3JCvr+TrnxdvWAX5hri4jBdN+xrPGcD4 I9Is4pV/lsLKKn2/5OxNjmKIbvSssf+k7RCahTKtyKFDcx5MxJmN2vCGvcgJlIgmkzZr vwOzjJrI9G7eJQJIEC+Ga7/GL2gIGw3tWY4EYb8OS4kgNeFEYfj5Tyej6xMERtLRnM4/ EVM0gggmoV5zTHzSpLHLFT/m89P12TjfdnlF/3ALvYLe9lVR8N7oZYcipkYRNjF+WXjw gFaVpJG29mGkXQ7PT8bYinsSDj3YXBLyGcv/CKh668g8RB1HzCTVVO4RISKpbOOD5ZqS M8yw== X-Gm-Message-State: ALoCoQk2FpE9q7MtXnh50MZy15jpTM9hB3vZ2/DF4XAIvN/1IZePC3HWut4536LKJ+kUP9uoOMGG X-Received: by 10.67.11.14 with SMTP id ee14mr16494201pad.107.1403744790539; Wed, 25 Jun 2014 18:06:30 -0700 (PDT) Received: from [10.1.1.4] (58-6-183-210.dyn.iinet.net.au. [58.6.183.210]) by mx.google.com with ESMTPSA id zq5sm7137530pbb.37.2014.06.25.18.06.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 18:06:29 -0700 (PDT) Message-ID: <53AB7212.5080902@linaro.org> Date: Thu, 26 Jun 2014 01:06:00 -0000 From: Kugan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jakub Jelinek CC: Richard Henderson , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH 1/2] Enable setting sign and unsigned promoted mode (SPR_SIGNED_AND_UNSIGNED) References: <53A9658F.2070304@linaro.org> <53A96657.1030901@linaro.org> <20140624121812.GW31640@tucnak.redhat.com> <53AA7864.9020500@linaro.org> <20140625075005.GY31640@tucnak.redhat.com> In-Reply-To: <20140625075005.GY31640@tucnak.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg02081.txt.bz2 On 25/06/14 17:50, Jakub Jelinek wrote: > On Wed, Jun 25, 2014 at 05:21:08PM +1000, Kugan wrote: >> The problem with SRP_POINTER 0, SRP_SIGNED 1, SRP_UNSIGNED 2, >> SRP_SIGNED_AND_UNSIGNED 3 (as I understand) is that, it will be >> incompatible with TYPE_UNSIGNED (tree) and defines of >> POINTER_EXTEND_UNSIGNED values. We will have to then translate while >> setting to SRP_* values . Also SUBREG_PROMOTED_SIGNED_P is now checked >> in some cases for != 0 (meaning SRP_POINTER or SRP_UNSIGNED) and in some >> cases > 0 (meaning SRP_UNSIGNED). >> >> Since our aim is to perform single bit checks, why don’t we just use >> this representation internally (i.e. _rtx->unchanging = 1 if SRP_SIGNED >> and _rtx->volatil = 1 if SRP_UNSIGNED). As for SUBREG_PROMOTED_SIGNED_P, >> we still have to return -1 or 1 depending on SRP_POINTER or SRP_UNSIGNED. > > Why don't you make SUBREG_PROMOTED_UNSIGNED_P just return 0/1 (i.e. the > single bit), and for places where it would like to match both > SRP_UNSIGNED and SRP_POINTER use SUBREG_PROMOTED_GET () & SRP_UNSIGNED > or so? If we use SUBREG_PROMOTED_GET () & SRP_UNSIGNED, we will miss the case SRP_SIGNED_AND_UNSIGNED. Though this is not wrong, we might miss some optimization opportunities here. We can however use (SUBREG_PROMOTED_GET () != SRP_SIGNED) if you like this. Other option is to define another macro that explicilty says some think like SUBREG_PROMOTED_POINTER_OR_UNSIGNED_P. >> --- a/gcc/ifcvt.c >> +++ b/gcc/ifcvt.c >> @@ -1448,8 +1448,11 @@ noce_emit_cmove (struct noce_if_info *if_info, rtx x, enum rtx_code code, >> || byte_vtrue != byte_vfalse >> || (SUBREG_PROMOTED_VAR_P (vtrue) >> != SUBREG_PROMOTED_VAR_P (vfalse)) >> - || (SUBREG_PROMOTED_UNSIGNED_P (vtrue) >> - != SUBREG_PROMOTED_UNSIGNED_P (vfalse))) >> + || ((SUBREG_PROMOTED_UNSIGNED_P (vtrue) >> + != SUBREG_PROMOTED_UNSIGNED_P (vfalse)) >> + && (SUBREG_PROMOTED_SIGNED_P (vtrue) >> + != SUBREG_PROMOTED_SIGNED_P (vfalse)))) > > Shouldn't this be SUBREG_PROMOTED_GET (vtrue) != SUBREG_PROMOTED_GET (vfalse) ? The reason why I checked like this to cover one side with SRP_SIGNED_AND_UNSIGNED and other with SRP_SIGNED or SRP_UNSIGNED. If we check SUBREG_PROMOTED_GET (vtrue) != SUBREG_PROMOTED_GET (vfalse) we will miss that. >> + >> +/* Predicate to check if RTX of SUBREG_PROMOTED_VAR_P() is promoted >> + for UNSIGNED type. In case of SRP_POINTER, SUBREG_PROMOTED_UNSIGNED_P >> + returns -1 as this is in most cases handled like unsigned extension, >> + except for generating instructions where special code is emitted for >> + (ptr_extend insns) on some architectures. */ >> #define SUBREG_PROMOTED_UNSIGNED_P(RTX) \ >> - ((RTL_FLAG_CHECK1 ("SUBREG_PROMOTED_UNSIGNED_P", (RTX), SUBREG)->volatil) \ >> - ? -1 : (int) (RTX)->unchanging) >> + ((((RTL_FLAG_CHECK1 ("SUBREG_PROMOTED_UNSIGNED_P", (RTX), SUBREG)->volatil)\ >> + + (RTX)->unchanging) == 0) ? -1 : ((RTX)->volatil == 1)) >> + >> +/* Checks if RTX of SUBREG_PROMOTED_VAR_P() is promotd for given SIGN. */ >> +#define SUBREG_CHECK_PROMOTED_SIGN(RTX, SIGN) \ > > Use space rather than tab. Also, why do we need this macro? > Can't you just use SUBREG_PROMOTED_GET () == sign ? I mean, sign in that > case is typically just 0 or 1. Again I wanted to cover SRP_SIGNED_AND_UNSIGNED as well in this case. Thanks, Kugan