From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-169377-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 23534 invoked by alias); 18 Jul 2011 18:01:00 -0000
Received: (qmail 23524 invoked by uid 22791); 18 Jul 2011 18:00:59 -0000
X-SWARE-Spam-Status: No, hits=-6.8 required=5.0	tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS
X-Spam-Check-By: sourceware.org
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 18 Jul 2011 18:00:41 +0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p6II0eNZ030789	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);	Mon, 18 Jul 2011 14:00:40 -0400
Received: from anchor.twiddle.net (vpn-226-15.phx2.redhat.com [10.3.226.15])	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p6II0eYR018152;	Mon, 18 Jul 2011 14:00:40 -0400
Message-ID: <4E2474C7.7030706@redhat.com>
Date: Mon, 18 Jul 2011 21:20:00 -0000
From: Richard Henderson <rth@redhat.com>
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 Thunderbird/3.1.10
MIME-Version: 1.0
To: Paul Koning <paul_koning@Dell.com>
CC: "Paulo J. Matos" <pocmatos@gmail.com>, gcc@gcc.gnu.org
Subject: Re: splitting add instructions
References: <j01hrs$9ra$1@dough.gmane.org> <4E246502.6070107@redhat.com> <948EFF37-272F-4ED4-AF6D-BFA05D8D6DF6@dell.com>
In-Reply-To: <948EFF37-272F-4ED4-AF6D-BFA05D8D6DF6@dell.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2011-07/txt/msg00310.txt.bz2

On 07/18/2011 10:29 AM, Paul Koning wrote:
> Why an add instruction? Is that in the case where address arithmetic
> requires separate adds?

I don't recall.  Probably to do with some edge case of reloading addresses.
I know that this affects m68k, which is even CISC-y-er in its addressing 
modes than pdp11, so I do know that you can't ignore it.

You could fairly easily find the case that requires it by adding a temporary

  gcc_assert (!reload_in_progress);

inside your Pmode add expander.

> "Specifically represent... the carry flag" means using the CCmode
> style of condition code handling, right?

Yes.


r~