From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id 6BC303858D28 for ; Mon, 8 May 2023 22:26:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6BC303858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pg1-x52f.google.com with SMTP id 41be03b00d2f7-52cbd7d0c37so2037531a12.3 for ; Mon, 08 May 2023 15:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683584808; x=1686176808; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=RDsTf/csGTyF/Q/PPrmCP2cQkbRJAYgOpV3+mgGYXq8=; b=HOMEzwutjqZxr/ICLxsj+ghBj6GaohoC46VFZUeMuk2eBF1PrDgO0yOrzXTxAUt2uP TL9J/unWAcX9el1uNAK+On5o7MhE5zcsddxfAOXqkwXhlX3oXLKyQinNOUC0t33uPfdb FaEqajky5gO1tMsi4MzeOvdimha46HCpjXbN5jAb6vQkE6rSLNcwcH0CGBF0/f8HAvw+ DAlxSauEz1VQQjuP8LWOZc5QL9a37b/CutUj34LNIV5k9i8W71T3vaFLumbG+97DncjN Q/7cEeNfcrnC4eGYekZg4GsJbA+yKRi6YyOYU8lEItrTXIq6uq73fydHX/KuK4OJiYAO lOig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683584808; x=1686176808; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RDsTf/csGTyF/Q/PPrmCP2cQkbRJAYgOpV3+mgGYXq8=; b=RRU+KP2B8pqYxrNUatL+ZihQUYE1MNQXmsuZVNqXArBKpglT4dX6NarvnO5wO0ete4 IZTAkwJozpESCM6VD43vdWKan4yi41pZJNXHashoUV+7YnpiAQG+9qti/d6HofiHYHDK psPwqXv/h9wvQpwIwFABXQftKxCYzzvI1zmDNEnKPiBuxv9Q03p76igue0nLW4N+9Y+u kIVVDmSr9dFJ3JafZI41pAiWY8L/Z9P2MQnHVWCuXlQU+BxhnMU5aLfEXlpk1FiTVyga /yRjLYOD4Fffac48NGDZN4x2nIA6mYoXFsBcYx3hCQTOYZfZcnKB4iEJQ67T+6801Ief ehDw== X-Gm-Message-State: AC+VfDzQwTYZkqPIiPyWrPkf+l72r+ZHcG/2QxzgqQ50qttXJ0F0/fVm yUQ+6xU754oDea/e0tmNnEA= X-Google-Smtp-Source: ACHHUZ7zs+ik4WnPuyWfn4Uu0tNXhkEACBj2gPA2aPxT3AjpTkt+4/LzZl2faBhrdKqNnLw1vftmTA== X-Received: by 2002:a05:6a21:3299:b0:100:6863:8be7 with SMTP id yt25-20020a056a21329900b0010068638be7mr6148510pzb.62.1683584808146; Mon, 08 May 2023 15:26:48 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::99f? ([2601:681:8600:13d0::99f]) by smtp.gmail.com with ESMTPSA id 9-20020a631949000000b005134fc049d7sm6766938pgz.31.2023.05.08.15.26.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 May 2023 15:26:47 -0700 (PDT) Message-ID: Date: Mon, 8 May 2023 16:26:45 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH v2] xtensa: Make full transition to LRA Content-Language: en-US To: Takayuki 'January June' Suwa , Richard Biener , GCC Patches Cc: Max Filippov References: <91ddbcb5-67e2-2c30-a81e-6b20e3c8e1a4.ref@yahoo.co.jp> <91ddbcb5-67e2-2c30-a81e-6b20e3c8e1a4@yahoo.co.jp> <42c4f026-3045-c469-e62f-24d7c26cd431@yahoo.co.jp> From: Jeff Law In-Reply-To: <42c4f026-3045-c469-e62f-24d7c26cd431@yahoo.co.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 5/8/23 08:44, Takayuki 'January June' Suwa via Gcc-patches wrote: > On 2023/05/08 22:43, Richard Biener wrote: > [snip] >>> -mlra >> >> If they were in any released compiler options should be kept >> (doing nothing) for backward compatibility. Use for example >> >> mlra >> Target WarnRemoved >> Removed in GCC 14. This switch has no effect. >> >> or >> >> mlra >> Target Ignore >> Does nothing. Preserved for backward compatibility. >> >> which doesn't inform the user (I think that's the better choice here). >> >>> -Target Mask(LRA) > Thank you for your helpful advice. > > ===== > gcc/ChangeLog: > > * config/xtensa/constraints.md (R, T, U): > Change define_constraint to define_memory_constraint. > * config/xtensa/xtensa.cc > (xtensa_lra_p, TARGET_LRA_P): Remove. > (xtensa_emit_move_sequence): Remove "if (reload_in_progress)" > clause as it can no longer be true. > (xtensa_output_integer_literal_parts): Consider 16-bit wide > constants. > (xtensa_legitimate_constant_p): Add short-circuit path for > integer load instructions. > * config/xtensa/xtensa.md (movsf): Use can_create_pseudo_p() > rather reload_in_progress and reload_completed. > * config/xtensa/xtensa.opt (mlra): Change to no effect. > --- > gcc/config/xtensa/constraints.md | 26 ++++++++------------------ > gcc/config/xtensa/xtensa.cc | 26 +++++--------------------- > gcc/config/xtensa/xtensa.md | 2 +- > gcc/config/xtensa/xtensa.opt | 4 ++-- > 4 files changed, 16 insertions(+), 42 deletions(-) > > diff --git a/gcc/config/xtensa/constraints.md b/gcc/config/xtensa/constraints.md > index 53e4d0d8dd1..9b31e162941 100644 > --- a/gcc/config/xtensa/constraints.md > +++ b/gcc/config/xtensa/constraints.md > @@ -123,29 +123,19 @@ > (and (match_code "const_int") > (match_test "! xtensa_split1_finished_p ()")))) > > -;; Memory constraints. Do not use define_memory_constraint here. Doing so > -;; causes reload to force some constants into the constant pool, but since > -;; the Xtensa constant pool can only be accessed with L32R instructions, it > -;; is always better to just copy a constant into a register. Instead, use > -;; regular constraints but add a check to allow pseudos during reload. > +;; Memory constraints. > > -(define_constraint "R" > +(define_memory_constraint "R" > "Memory that can be accessed with a 4-bit unsigned offset from a register." > - (ior (and (match_code "mem") > - (match_test "smalloffset_mem_p (op)")) > - (and (match_code "reg") > - (match_test "reload_in_progress > - && REGNO (op) >= FIRST_PSEUDO_REGISTER")))) > + (and (match_code "mem") > + (match_test "smalloffset_mem_p (op)"))) > > -(define_constraint "T" > +(define_memory_constraint "T" > "Memory in a literal pool (addressable with an L32R instruction)." > (and (match_code "mem") > (match_test "!TARGET_CONST16 && constantpool_mem_p (op)"))) > > -(define_constraint "U" > +(define_memory_constraint "U" > "Memory that is not in a literal pool." > - (ior (and (match_code "mem") > - (match_test "! constantpool_mem_p (op)")) > - (and (match_code "reg") > - (match_test "reload_in_progress > - && REGNO (op) >= FIRST_PSEUDO_REGISTER")))) > + (and (match_code "mem") > + (match_test "! constantpool_mem_p (op)"))) Given the old comment, you might want to use define_special_memory_constraint rather than define_memory_constraint. It might be worth doing some before/after comparisons to see if there's any noticeable impact. jeff