From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-170905-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 16951 invoked by alias); 26 Oct 2011 02:58:29 -0000
Received: (qmail 16942 invoked by uid 22791); 26 Oct 2011 02:58:28 -0000
X-SWARE-Spam-Status: No, hits=-1.3 required=5.0	tests=AWL,BAYES_00,MIME_QP_LONG_LINE
X-Spam-Check-By: sourceware.org
Received: from c60.cesmail.net (HELO c60.cesmail.net) (216.154.195.49)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 26 Oct 2011 02:58:13 +0000
Received: from unknown (HELO epsilon2) ([192.168.1.60])  by c60.cesmail.net with ESMTP; 25 Oct 2011 22:58:12 -0400
Received: from host-92-29-214-155.as13285.net	(host-92-29-214-155.as13285.net [92.29.214.155]) by webmail.spamcop.net	(Horde MIME library) with HTTP; Tue, 25 Oct 2011 22:58:12 -0400
Message-ID: <20111025225812.6t04cg8mecckocoo-nzlynne@webmail.spamcop.net>
Date: Wed, 26 Oct 2011 03:53:00 -0000
From: Joern Rennecke <amylaar@spamcop.net>
To: DJ Delorie <dj@redhat.com>
Cc: gcc@gcc.gnu.org
Subject: Re: Impact assessment of dse.c:emit_inc_dec_insn_before (Was: Re:	Use of FLAGS_REGNUM clashes with generates insn)
References: <j5fv45$ge7$1@dough.gmane.org>	<20110923032116.4fzwmhwd44ckgwwk-nzlynne@webmail.spamcop.net>	<alpine.BSF.2.00.1110170004190.39960@dair.pair.com>	<20111018062749.ff87vnia88g0kkc8-nzlynne@webmail.spamcop.net>	<20111025202444.4fr6ofn1kogkc0co-nzlynne@webmail.spamcop.net>	<201110260155.p9Q1tJ0l015827@greed.delorie.com>
In-Reply-To: <201110260155.p9Q1tJ0l015827@greed.delorie.com>
MIME-Version: 1.0
Content-Type: text/plain;	charset=UTF-8;	DelSp="Yes";	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.4)
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-10/txt/msg00463.txt.bz2

Quoting DJ Delorie <dj@redhat.com>:

>
>> m32c.c:m32c_legitimate_address_p allows any rubbish inside a
>> PRE_MODIFY, as long as the address register is the stack pointer.
>> OTOH, it does not define any HAVE_*_MODIFY_* macro.
>
> m32c has push/pop and no other pre/post modify
I was talking about what addresses are allowed by
the TARGET_LEGITIMATE_ADDRESS_P, not what the hardware implements or
what the register allocator is guided to produce; some optimizers can
get quite 'creative' in mashing rtl together.

Considering the following stanza from m32c_legitimate_address_p,
I don't see how it would reject
(pre_modify:HI
   (reg:CC SP_REGNO)
   (cond_exec:V2HI (pc:SC)
                   (if_then_else:PSI (scratch:BLK) (reg 4004) (return:QI))))


   /* allowing PLUS yields mem:HI(plus:SI(mem:SI(plus:SI in m32c_split_move=
 */
   if (GET_CODE (x) =3D=3D PRE_DEC
       || GET_CODE (x) =3D=3D POST_INC || GET_CODE (x) =3D=3D PRE_MODIFY)
     {
       return (GET_CODE (XEXP (x, 0)) =3D=3D REG
               && REGNO (XEXP (x, 0)) =3D=3D SP_REGNO);
     }