From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11572 invoked by alias); 19 Jun 2013 19:46:49 -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 11563 invoked by uid 89); 19 Jun 2013 19:46:49 -0000 X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS autolearn=ham version=3.3.1 Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 19 Jun 2013 19:46:48 +0000 Received: by mail-wi0-f179.google.com with SMTP id hj3so1018124wib.6 for ; Wed, 19 Jun 2013 12:46:46 -0700 (PDT) X-Received: by 10.194.123.69 with SMTP id ly5mr3411094wjb.29.1371671206234; Wed, 19 Jun 2013 12:46:46 -0700 (PDT) Received: from localhost ([2.26.204.199]) by mx.google.com with ESMTPSA id f8sm11325448wiv.0.2013.06.19.12.46.45 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 19 Jun 2013 12:46:45 -0700 (PDT) From: Richard Sandiford To: Vladimir Makarov Mail-Followup-To: Vladimir Makarov ,GCC Patches , rdsandiford@googlemail.com Cc: GCC Patches Subject: Re: patch to fix PR57559 for s390 References: <51B37A3F.1060705@redhat.com> <87zjuv3t9m.fsf@talisman.default> <87k3lqlzpr.fsf@talisman.default> <51C1FD99.8010404@redhat.com> Date: Wed, 19 Jun 2013 19:46:00 -0000 In-Reply-To: <51C1FD99.8010404@redhat.com> (Vladimir Makarov's message of "Wed, 19 Jun 2013 14:51:05 -0400") Message-ID: <87fvwdnasd.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-06/txt/msg01159.txt.bz2 Vladimir Makarov writes: > On 13-06-19 2:31 PM, Richard Sandiford wrote: >> Richard Sandiford writes: >>> Vladimir Makarov writes: >>>> Index: lra.c >>>> =================================================================== >>>> --- lra.c (revision 199753) >>>> +++ lra.c (working copy) >>>> @@ -306,11 +306,11 @@ lra_emit_add (rtx x, rtx y, rtx z) >>>> || (disp != NULL_RTX && ! CONSTANT_P (disp)) >>>> || (scale != NULL_RTX && ! CONSTANT_P (scale))) >>>> { >>>> - /* Its is not an address generation. Probably we have no 3 op >>>> + /* It is not an address generation. Probably we have no 3 op >>>> add. Last chance is to use 2-op add insn. */ >>>> lra_assert (x != y && x != z); >>>> - emit_move_insn (x, z); >>>> - insn = gen_add2_insn (x, y); >>>> + emit_move_insn (x, y); >>>> + insn = gen_add2_insn (x, z); >>>> emit_insn (insn); >>>> } >>>> else >>> Could you add a comment to lra_emit_add saying why it has to be this >>> way round (move y, add z)? >> Ping. > I am going to add a comment when I submit my next patch (it will happen > today or tomorrow). Thanks. > The reason is simple as address segment is stored in y not in z and > generation of addition of address segment to pseudo can fail (that is > what happens for the PR). Do you mean address segment in the x86 sense of "segment"? I was just a bit confused because the current comment says "It is not an address generation", whereas it sounds like addresses are involved somewhere. I suppose the commutation rules are that Y should be "no less complicated" than Z, so maybe it wins from that point of view too. Richard