From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id 5F2923857C60 for ; Fri, 30 Apr 2021 12:50:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5F2923857C60 Received: by mail-ot1-x32b.google.com with SMTP id g7-20020a9d5f870000b02902a5831ad705so1089129oti.10 for ; Fri, 30 Apr 2021 05:50:08 -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:content-transfer-encoding; bh=/NOg8ne4f6q8w7SgdTosFe+r9noxPPHyIcgyZyxTlLc=; b=TzuD/pynzsCtGFdr17mHkjp2Gnf2OeWKrejNqFlLq3zKyFLTeCIC7WGaSXj6oinhpS Gyo6Nh4KSMgCgJumG6yk6BRtmp4EnQdrHX/UOxRp+d0lB78QrXAjv3UR8VlRkZIeW+UK KCqWAL23ApHSrPAHnU3EyrKdmI2J3FPrj1pKKxIYLjWc8GYZ2RQMh4DDhfCwNZVa0khK 08PSFvdGDOmtnQK6KTqEXCustOLlAXWQVBYAXugNshEdnedlZYPvcTxQrjZL9I4wXvEL RAFPT3BoStZqGbA1k0GFdNotnXDDd0wj57hCFcyc7mGrV0MsP4NOVm1BDYrXjbavwjo4 8o0g== X-Gm-Message-State: AOAM5322UOETJ6+gv9bgdlMS0piQ3xNvPw7zOslxyc2simnMdxanSZ73 XzVf3WbXrFHYcxPihgLguc0NpY7tzEhx0IoBlwNTjBd0KCM= X-Google-Smtp-Source: ABdhPJw3ZWBDGmKDK+FClZazAuPJ5rmelN21ZiF0klSPnqthOAmhOGcyhnsdPZk4pzrbkjTwjstwACgP8xEVHaJ6VbQ= X-Received: by 2002:a9d:6f19:: with SMTP id n25mr3518864otq.89.1619787007267; Fri, 30 Apr 2021 05:50:07 -0700 (PDT) MIME-Version: 1.0 References: <20210429125415.1634118-1-hjl.tools@gmail.com> <20210429125415.1634118-3-hjl.tools@gmail.com> In-Reply-To: From: "H.J. Lu" Date: Fri, 30 Apr 2021 05:49:31 -0700 Message-ID: Subject: Re: [PATCH 02/12] Allow generating pseudo register with specific alignment To: "H.J. Lu via Gcc-patches" , Richard Sandiford Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3028.3 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Fri, 30 Apr 2021 12:50:09 -0000 On Fri, Apr 30, 2021 at 5:42 AM Richard Sandiford wrote: > > "H.J. Lu via Gcc-patches" writes: > > On Fri, Apr 30, 2021 at 2:06 AM Richard Sandiford > > wrote: > >> > >> "H.J. Lu via Gcc-patches" writes: > >> > gen_reg_rtx tracks stack alignment needed for pseudo registers so th= at > >> > associated hard registers can be properly spilled onto stack. But t= here > >> > are cases where associated hard registers will never be spilled onto > >> > stack. gen_reg_rtx is changed to take an argument for register alig= nment > >> > so that stack realignment can be avoided when not needed. > >> > >> How is it guaranteed that they will never be spilled though? > >> I don't think that that guarantee exists for any kind of pseudo, > >> except perhaps for the temporary pseudos that the RA creates to > >> replace (match_scratch =E2=80=A6)es. > >> > > > > The caller of creating pseudo registers with specific alignment must > > guarantee that they will never be spilled. I am only using it in > > > > /* Make operand1 a register if it isn't already. */ > > if (can_create_pseudo_p () > > && !register_operand (op0, mode) > > && !register_operand (op1, mode)) > > { > > /* NB: Don't increase stack alignment requirement when forcing > > operand1 into a pseudo register to copy data from one memory > > location to another since it doesn't require a spill. */ > > emit_move_insn (op0, > > force_reg (GET_MODE (op0), op1, > > (UNITS_PER_WORD * BITS_PER_UNIT))); > > return; > > } > > > > for vector moves. RA shouldn't spill it. > > But this is the point: it's a case of hoping that the RA won't spill it, > rather than having a guarantee that it won't. > > Even if the moves start out adjacent, they could be separated by later > RTL optimisations, particularly scheduling. (I realise pre-RA scheduling > isn't enabled by default for x86, but it can still be enabled explicitly.= ) > Or if the same data is being copied to two locations, we might reuse > values loaded by the first copy for the second copy as well. > > The only way to guarantee that the temporary won't be spilled is to hide > it until after RA. > Let me think about it. --=20 H.J.