From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12138 invoked by alias); 11 Jul 2011 11:03:26 -0000 Received: (qmail 12130 invoked by uid 22791); 11 Jul 2011 11:03:25 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_XF X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Jul 2011 11:03:11 +0000 Received: by wwj26 with SMTP id 26so3391943wwj.8 for ; Mon, 11 Jul 2011 04:03:10 -0700 (PDT) Received: by 10.216.233.211 with SMTP id p61mr3871553weq.107.1310382190426; Mon, 11 Jul 2011 04:03:10 -0700 (PDT) Received: from yakj.usersys.redhat.com (93-34-199-31.ip51.fastwebnet.it [93.34.199.31]) by mx.google.com with ESMTPS id 53sm1839631wel.31.2011.07.11.04.03.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jul 2011 04:03:08 -0700 (PDT) Message-ID: <4E1AD86A.8000800@gnu.org> Date: Mon, 11 Jul 2011 11:09:00 -0000 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Mnenhy/0.8.3 Thunderbird/3.1.10 MIME-Version: 1.0 To: "H.J. Lu" CC: GCC Patches Subject: Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant References: <4E18C5BE.6020809@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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: 2011-07/txt/msg00798.txt.bz2 On 07/11/2011 02:04 AM, H.J. Lu wrote: > With my original change, I got > > (const:DI (plus:DI (symbol_ref:DI ("iplane.1577") [flags 0x2] > ) > (const_int -4 [0xfffffffffffffffc]))) > > I think it is safe to permute the conversion and addition operation > if one operand is a constant and we are zero-extending. This is > how zero-extending works. Ok, I think I understand what you mean. The key is the XEXP (x, 1) == convert_memory_address_addr_space (to_mode, XEXP (x, 1), as) test. It ensures basically that the constant has 31-bit precision, because otherwise the constant would change from e.g. (const_int -0x7ffffffc) to (const_int 0x80000004) when zero-extending it from SImode to DImode. But I'm not sure it's safe. You have, (zero_extend:DI (plus:SI FOO:SI) (const_int Y)) and you want to convert it to (plus:DI FOO:DI (zero_extend:DI (const_int Y))) (where the zero_extend is folded). Ignore that FOO is a SYMBOL_REF (this piece of code does not assume anything about its shape); if FOO == 0xfffffffc and Y = 8, the result will be respectively 0x4 (valid) and 0x100000004 (invalid). If pointers extend as signed you also have a similar case. If FOO == 0x7ffffffc and Y = 8, the result of (sign_extend:DI (plus:SI FOO:SI) (const_int Y)) and (plus:DI FOO:DI (sign_extend:DI (const_int Y))) will be respectively 0xffffffff80000004 (valid) and 0x80000004 (invalid). What happens if you just return NULL instead of the assertion (good idea adding it!)? Of course then you need to: 1) check the return values of convert_memory_address_addr_space_1, and propagate NULL up to simplify_unary_operation; 2) check in simplify-rtx.c whether the return value of convert_memory_address_1 is NULL, and only return if the return value is not NULL. This is not yet necessary (convert_memory_address is the last transformation for both SIGN_EXTEND and ZERO_EXTEND) but it is better to keep code clean. Thanks, Paolo