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 3626B3851C1D for ; Fri, 30 Apr 2021 13:35:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3626B3851C1D Received: by mail-ot1-x32b.google.com with SMTP id 65-20020a9d03470000b02902808b4aec6dso59639852otv.6 for ; Fri, 30 Apr 2021 06:35:13 -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=1OVhzacfDm7Km0MWPupMmK0XhImvpo55FFsZ/Yvp2Cw=; b=nNMZaAk2TfDafnySB3XEfjK8VkpkiBWXFirBmULQwPdkaUn0kGL/dR0lapuX25FFYg KRd/31L/OU15XbRH6sX2w0O9/d84L0HyNA+kNjF0X+j3xNnjKb3HH/ovFoTOiY+fL1uA u4gajFdd80oDrD1Uy5WMAtoTjSce9N3LuRlMAtf1ZTzYFTAnbA/FUOwHQ0s5rtEeWCvx VoTvprpNRID7lNfsWQo3xa78vslxQoZ1lbPFRtX6U6yprILBRozKi0O9uz3yf/xnHhJw MNmh/8BREbt5JoGoHE09AXJ93CP11Bhsqe8989KVKtGuJUD7hUvKR9LBY+BPaMD+BST3 9Crw== X-Gm-Message-State: AOAM532fX42VNNzsJP5MczeIQP+ovDzvbuWgjtmuLG2ZfYGgbYaH6wk/ GALgSe0/pAXGDo4ICwPp+OdKmQiU1FOoCY6wYUg402q6Vk1FDA== X-Google-Smtp-Source: ABdhPJzujGApbWmEy0chkqdkJZwgnR5Lm/QIauMCucKns1xm0gRuqh+4qfEhjQw51BWswhceiaM5K4ZZUAxp3xA0lg8= X-Received: by 2002:a05:6830:1e2f:: with SMTP id t15mr3788094otr.125.1619789712123; Fri, 30 Apr 2021 06:35:12 -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 06:34:36 -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 13:35:14 -0000 On Fri, Apr 30, 2021 at 5:49 AM H.J. Lu wrote: > > 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 = that > > >> > associated hard registers can be properly spilled onto stack. But= there > > >> > are cases where associated hard registers will never be spilled on= to > > >> > stack. gen_reg_rtx is changed to take an argument for register al= ignment > > >> > 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 scheduli= ng > > isn't enabled by default for x86, but it can still be enabled explicitl= y.) > > 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. There are cases where pseudo vector registers are created as pure temporary registers in the backend and they shouldn't ever be spilled to stack. They will be spilled to stack only if there are other non-tempo= rary vector register usage in which case stack will be properly re-aligned. Caller of creating pseudo registers with specific alignment guarantees that they are used only as pure temporary registers. > > The only way to guarantee that the temporary won't be spilled is to hid= e > > it until after RA. > > > > Let me think about it. > > -- > H.J. --=20 H.J.