From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id E16A63899435 for ; Mon, 3 May 2021 08:19:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E16A63899435 Received: by mail-ed1-x533.google.com with SMTP id di13so5320953edb.2 for ; Mon, 03 May 2021 01:19:04 -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=cWG2jwtTmfKQFMnOmaq1X5WyeQp+O5AJIS5mlDhcTSg=; b=SNFq1ObeIxc657/8V4WTC12M5XRs4PZNsnv17yvHPU9weSRNGQIfJseXvOOlbzJiEn xgg56DNrbvU4X+tG2vq5p77dImT1xg2dymX0WiroTTPB4m3ybHiS6b5zAefJO30YjGdC ugC4+/XjKH1NwKIBK8AHNVUMP/xgkgyh2i7PVPPmW+WRm3XdiMMeMlLbgluw3ZlWRDjS 08pjteBV5LfQmTWwI745YhWyuU113pECmOlESkIT3gYL9CSc3LolNLATBqFkybgsGA/X cY74HU1B+m3qde8dg0+OuXqMCVHuMt6xjZ1QDgwvwJV0/gbUwci0zNUqbP0oVSJy4b9M TWFQ== X-Gm-Message-State: AOAM531xlDxFMrfs+87rYjPpJg4UKD2gq1hW+br42C+G1/rKH6xyRmy3 Y5IdwKnU6Hb4qsHm4IToqXE2IW15+IZ7RHuHBkU= X-Google-Smtp-Source: ABdhPJzsG81bHwQLOn2AnsMZNFcb3PTy+nt/U9YRifXJEl6kRcPm/AGDU3wLP3Vir/HNeQTwNAgmIhlgPmfPp/Tq568= X-Received: by 2002:a05:6402:2d6:: with SMTP id b22mr18854941edx.274.1620029944016; Mon, 03 May 2021 01:19:04 -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: Richard Biener Date: Mon, 3 May 2021 10:18:52 +0200 Message-ID: Subject: Re: [PATCH 02/12] Allow generating pseudo register with specific alignment To: Richard Sandiford , "H.J. Lu via Gcc-patches" , "H.J. Lu" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.9 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: Mon, 03 May 2021 08:19:08 -0000 On Fri, Apr 30, 2021 at 8:30 PM Richard Sandiford via Gcc-patches wrote: > > "H.J. Lu via Gcc-patches" writes: > > 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= onto > >> > >> > stack. gen_reg_rtx is changed to take an argument for register= alignment > >> > >> > 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 mu= st > >> > > 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 forci= ng > >> > > operand1 into a pseudo register to copy data from one mem= ory > >> > > 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 lat= er > >> > RTL optimisations, particularly scheduling. (I realise pre-RA sched= uling > >> > isn't enabled by default for x86, but it can still be enabled explic= itly.) > >> > 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-t= emporary > > 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. > > I don't think there's really a distinct category of pure temporary > registers though. The things I mentioned above can happen for any > kind of pseudo register. I wonder if for the cases HJ thinks of it is appropriate to use hardregs? Do we generally handle those well? That is, are they again subject to be allocated by RA when no longer live? Richard. > Thanks, > Richard