From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16128 invoked by alias); 22 Oct 2014 20:02:53 -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 16083 invoked by uid 89); 22 Oct 2014 20:02:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 22 Oct 2014 20:02:52 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9MK2nkt010379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 22 Oct 2014 16:02:50 -0400 Received: from [10.3.113.119] (ovpn-113-119.phx2.redhat.com [10.3.113.119]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9MK2neW001345; Wed, 22 Oct 2014 16:02:49 -0400 Message-ID: <54480D68.8090709@redhat.com> Date: Wed, 22 Oct 2014 20:31:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Maxim Kuvyrkov , GCC Patches Subject: Re: [PATCH 6/8] Handle SCRATCH in decompose_address References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg02302.txt.bz2 On 10/20/14 21:35, Maxim Kuvyrkov wrote: > Hi, > > This patch is a simple fix to allow decompose_address to handle > SCRATCH'es during 2nd scheduler pass. This patch is a prerequisite > for a scheduler improvement that relies on decompose_address to parse > insns. > > Bootstrapped and regtested on x86_64-linux-gnu and regtested on > arm-linux-gnueabihf and aarch64-linux-gnu. I'd like to see some further discussion here. get_base_term is supposed to look at its argument as a base address. I'm curious under what circumstances you want to have a SCRATCH as a base address? I didn't see anything in patch #8 which obviously dependended on this, but maybe it's in there, but more subtle than expected. If you can justify why it's useful to handle scratch in here, then the patch will be fine. jeff