From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8342 invoked by alias); 27 Jun 2011 16:04:14 -0000 Received: (qmail 8317 invoked by uid 22791); 27 Jun 2011 16:04:12 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-qw0-f47.google.com (HELO mail-qw0-f47.google.com) (209.85.216.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 27 Jun 2011 16:03:57 +0000 Received: by qwh5 with SMTP id 5so2650374qwh.20 for ; Mon, 27 Jun 2011 09:03:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.18.77 with SMTP id v13mr4831743qca.56.1309190636997; Mon, 27 Jun 2011 09:03:56 -0700 (PDT) Received: by 10.229.238.19 with HTTP; Mon, 27 Jun 2011 09:03:56 -0700 (PDT) In-Reply-To: <201106271452.p5REqu7U030984@d06av02.portsmouth.uk.ibm.com> References: <20110625184145.GA9684@intel.com> <201106271452.p5REqu7U030984@d06av02.portsmouth.uk.ibm.com> Date: Mon, 27 Jun 2011 16:16:00 -0000 Message-ID: Subject: Re: PATCH [11/n]: Prepare x32: PR rtl-optimization/48155: Reload doesn't handle subreg properly From: "H.J. Lu" To: Ulrich Weigand Cc: gcc-patches@gcc.gnu.org, bernds@codesourcery.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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-06/txt/msg02007.txt.bz2 On Mon, Jun 27, 2011 at 7:52 AM, Ulrich Weigand wrote: > H.J. Lu wrote: > >> Given input: >> >> (plus:SI (subreg:SI (plus:DI (reg/f:DI 7 sp) >> =A0 =A0 =A0 =A0 =A0 =A0 (const_int 16 [0x10])) 0) >> =A0 =A0 (const_int -1 [0xffffffffffffffff])) > > Once again, this seems weird as legitimate address ... =A0If this really > can occur validly, there'll probably need to be an insn+splitter and/or > a secondard reload provided by the back-end to handle it. This is the valid memory address for any instructions which take a memory operand under x32. How will insn+splitter and/or a secondard reload help x32 here? Do I implement such a thing for all instructions which take a memory operand? >> reloads tries to add >> >> (subreg:SI (plus:DI (reg/f:DI 7 sp) >> =A0 =A0 =A0 =A0 (const_int 16 [0x10])) 0) >> >> to >> >> (reg:SI 1 dx) > > And what happens then? =A0If the only problem is that this is then > rejected by the back-end, I don't think we need to change anything > in gen_reload ... > > With your change below, it seems you're just falling through to > the generic gen_rtx_SET case, right? =A0 How does this help? > I added ix86_simplify_base_disp to i386.c to handle such cases. It translates (set (reg:SI 40 r11) (plus:SI (plus:SI (mult:SI (reg:SI 1 dx) (const_int 8)) (subreg:SI (plus:DI (reg/f:DI 7 sp) (const_int CONST1)) 0)) (const_int CONST2))) into (set (reg:SI 40 r11) (plus:SI (plus:SI (mult:SI (reg:SI 1 dx) (const_int 8)) (reg/f:SI 7 sp)) (const_int [CONST1 + CONST2]))) It also translates (plus:DI (zero_extend:DI (plus:SI (plus:SI (reg:SI 4 si [70]) (reg:SI 2 cx [86])) (const_int CONST1))) (const_int CONST2)) into (plus:DI (zero_extend:DI (plus:SI (reg:SI 4 si [70]) (reg:SI 2 cx [86])) (const_int [CONST1 + CONST2]))) It also translates (plus:SI (plus:SI (plus:SI (reg:SI 4 si [70]) (reg:SI 2 cx [86])) (symbol_ref:SI ("A.193.2210"))) (const_int CONST)) into (plus:SI (plus:SI (reg:SI 4 si [70]) (reg:SI 2 cx [86])) (const (plus:SI (symbol_ref:SI ("A.193.2210")) (const_int CONST)))) It aslo translates (set (reg:SI 40 r11) (plus:SI (plus:SI (reg:SI 1 dx) (subreg:SI (plus:DI (reg/f:DI 7 sp) (const_int CONST1)) 0)) (const_int CONST2))) into (set (reg:SI 40 r11) (plus:SI (plus:SI (reg:SI 1 dx) (reg/f:SI 7 sp)) (const_int [CONST1 + CONST2]))) --=20 H.J.