From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id A5C683857432 for ; Mon, 6 Sep 2021 10:58:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A5C683857432 Received: by mail-ej1-x634.google.com with SMTP id a25so12720798ejv.6 for ; Mon, 06 Sep 2021 03:58:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AGaQ+I3MZFqMimR88wDabTLGH/vEky+Y+S0MQa4m4Cs=; b=aP1TecpFDg40yVL4nXKksd0kcGrZfq1yBHax/vC+HNeCYxqC/vpFmv/SL6bd0sJyI4 Ff7/RyyNIk/wMt/60LE2eoYv8R2+kZk5880OHN1TveZ4ij07KJVrrzn7yrpr6sORZWvp 0JETpflBZKrAavuWNZOu1SSSz8JnG9Rt7lj4+OZSZdHKsaMvMUbmqCvJ78nP9x1F034P 9UaMD7jD4WbZiQNSVXcJjICuGw84GJENYeDX4SgAZqDvjPQ/qz9NZISXIsQZ96um9jZ+ zZB8deVCW6lGyVL3DWYEsiIsa/sPaw7fQUZjP26IubpJpq03IXScQrv3rBxCtUAoNRd6 Klpg== X-Gm-Message-State: AOAM530WrnUP9xzvcu2ZknTMqxCANk157FH+XxOe1lUGm07LuyGISmv+ loESK0yj784C6COPF/pdw/2KEJGYvPORuFtvgBM= X-Google-Smtp-Source: ABdhPJyjSIZE55TwWiKppVouS2ww72wkaXus9Z2BUAnjh/oEa6HhCuUGeOd+HbSxD2rqDuPfUFl6iHVSFWUuV5U0rb0= X-Received: by 2002:a17:906:584:: with SMTP id 4mr13049653ejn.56.1630925898715; Mon, 06 Sep 2021 03:58:18 -0700 (PDT) MIME-Version: 1.0 References: <20210906104018.2697413-1-rearnsha@arm.com> <20210906104018.2697413-2-rearnsha@arm.com> In-Reply-To: <20210906104018.2697413-2-rearnsha@arm.com> From: Richard Biener Date: Mon, 6 Sep 2021 12:58:07 +0200 Message-ID: Subject: Re: [PATCH 1/3] rtl: allow forming subregs of already unaligned mems [PR102125] To: Richard Earnshaw Cc: GCC Patches , Bernd Edlinger Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 10:58:20 -0000 On Mon, Sep 6, 2021 at 12:40 PM Richard Earnshaw wrote: > > > GCC was recently changed to prevent simplify_subreg from simplifying > a subreg of a mem when the mode of the new mem would have stricter alignment > constraints than the inner mem already has when the target requires > STRICT_ALIGNMENT. > > However, such targets may have specialist patterns that can handle > unaligned accesses and this restriction turns out to be unduly restrictive. > So limit this restriction to only apply when the inner mem is naturally > aligned to the inner mode. Hmm, I think this can end up either generating wrong code or recog fails. The specific combination of alignment and mode of 'op' has been validated to be supported, replacing the mode with sth else would need re-validation of the combination. I'm not sure we can for example just query movmisalign support here and hope for LRA to reload the mem with that. So - where do you run into this? Is it possible to catch the situation on a higher level where more context as in the whole insn is visible? Thanks, Richard. > > gcc/ChangeLog: > > PR target/102125 > * simplify-rtx.c (simplify_context::simplify_subreg): Allow > simplifying (subreg (mem())) when the inner mem is already > misaligned for its type. > --- > gcc/simplify-rtx.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) >