From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-297230-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 6832 invoked by alias); 19 Jul 2011 11:43:08 -0000
Received: (qmail 6821 invoked by uid 22791); 19 Jul 2011 11:43:07 -0000
X-SWARE-Spam-Status: No, hits=-2.2 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-pv0-f175.google.com (HELO mail-pv0-f175.google.com) (74.125.83.175)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Jul 2011 11:42:52 +0000
Received: by pvf24 with SMTP id 24so4150831pvf.20        for <gcc-patches@gcc.gnu.org>; Tue, 19 Jul 2011 04:42:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.254.21 with SMTP id b21mr3655910wfi.249.1311075771593; Tue, 19 Jul 2011 04:42:51 -0700 (PDT)
Received: by 10.142.89.19 with HTTP; Tue, 19 Jul 2011 04:42:51 -0700 (PDT)
In-Reply-To: <g4bowqwm0b.fsf@linaro.org>
References: <20110709222042.GA4018@intel.com>	<CAFULd4bDzgO8w+VixUQBb0fA80rRgdNTKP5KVAJo9GWRM2f+zQ@mail.gmail.com>	<CAMe9rOrJ0qyNtaoQ57vowvERrLNadQayjbqM0q-1+T91=DZC5Q@mail.gmail.com>	<CAFULd4ZFAy2Cu4=xT7yHWKCF9tmPgDdt-w=qEcmKx6A2sBV_NQ@mail.gmail.com>	<CAMe9rOqa5Vs4A4xrF1keEokRMuWvDXyqdAuHbwn+Q7uZq_N8ag@mail.gmail.com>	<CAFULd4YvWzP_-qA-Bneja1rqLa-b8GKxYD4_6p8BQUGJH2NBZQ@mail.gmail.com>	<CAMe9rOq3KpA_uLU2WvXt5y5bHu7Ao7WgmwQca4nvFDJu0cViNQ@mail.gmail.com>	<CAFULd4bx7EJ6L=nS3LZO3A6niMP5xBGtYJ1P9p1DtgrpPJLFqw@mail.gmail.com>	<CAMe9rOoKT9UjsNUOJc18q40-gj-H7kJ4is1eAEDuTvi3EOpsMg@mail.gmail.com>	<CAMe9rOqCDYfuC-4QiCYyFe7--wkhSO_jVPO5PgRP_BvuXb+BTA@mail.gmail.com>	<CAFULd4YfMVngcPe-37d_EJ+Ogd2_s249o4SsJyZcTU0o2DFP7A@mail.gmail.com>	<g4bowqwm0b.fsf@linaro.org>
Date: Tue, 19 Jul 2011 12:11:00 -0000
Message-ID: <CAFULd4Z_XGoM351q5g2===LYrW0V5A4tZaNvw3AT-pe0rmaAnQ@mail.gmail.com>
Subject: Re: PATCH [5/n] X32: Supprot 32bit address
From: Uros Bizjak <ubizjak@gmail.com>
To: Uros Bizjak <ubizjak@gmail.com>, "H.J. Lu" <hjl.tools@gmail.com>, gcc-patches@gcc.gnu.org, 	Richard Henderson <rth@redhat.com>, jh@suse.cz, Richard Guenther <rguenther@suse.de>, 	Jakub Jelinek <jakub@redhat.com>, richard.sandiford@linaro.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2011-07/txt/msg01499.txt.bz2

On Tue, Jul 19, 2011 at 1:25 PM, Richard Sandiford
<richard.sandiford@linaro.org> wrote:

>> On Sat, Jul 16, 2011 at 6:47 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>> Yes, this is an example from PR I am referring to. Did you try to
>>>>> define LEGITIMIZE_RELOAD_ADDRESS? It is supposed to fix this.
>>>>>
>>>>
>>>> They make things even more complex. ix86_simplify_base_index_disp
>>>> is called after reload is done since we can do this translation safely
>>>> only on hard registers, not on pseudo registers.
>>>>
>>>
>>> Hi Uros,
>>>
>>> The current implementation =A0has been tested extensively. I'd like to =
keep
>>> it ASIS so that we can have a working x32 support. =A0We will revisit i=
t later:
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D49765
>>>
>>> after we have a working x32 GCC.
>>
>> This can not be only my decision, I have CCd other x86 maintainers and
>> RMs for their opinion on this question.
>
> FWIW, I agree with you that things like:
>
> =A0 (set (reg:SI 40 r11)
> =A0 =A0 =A0 =A0(plus:SI (plus:SI (mult:SI (reg:SI 1 dx)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (cons=
t_int 8))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(subreg:SI (plus:DI (r=
eg/f:DI 7 sp)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0(const_int CONST1)) 0))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (const_int CONST2)))
>
> do not look like things that should ever enter the insn stream.
> They're liable to confuse other code besides the x86 predicates.
> The target of the conversion:
>
> =A0 (set (reg:SI 40 r11)
> =A0 =A0 =A0 =A0(plus:SI (plus:SI (mult:SI (reg:SI 1 dx)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (cons=
t_int 8))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(reg/f:SI 7 sp))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (const_int [CONST1 + CONST2])))
>
> looks like the generally preferred form. =A0It isn't an x32-ism.
>
> LEGITIMIZE_RELOAD_ADDRESS is supposed to be for optimisation only,
> not correctness. =A0Why doesn't reload have enough information to
> generate the correct form itself?

Please see the solution at [1]. The problem was that x86 target
allowed SImode subregs of DImode operations (i.e. PLUS).  When these
are rejected, everything works as expected.

IMO, LEGITIMIZE_RELOAD_ADDRESS can not optimize resulting RTX, as shown in =
[1].

[1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01427.html

Uros.