From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) by sourceware.org (Postfix) with ESMTPS id 4CA17385800A for ; Fri, 14 May 2021 02:22:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4CA17385800A Received: by mail-ua1-x930.google.com with SMTP id g24so9184975uak.11 for ; Thu, 13 May 2021 19:22:37 -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=MftFRZe6X/STgk/DVN2f/dNyppM+1xB2niISy5lU0Io=; b=USeGcd7mYAl9+9yxYX97oEJSnW3MrB1uQK0zt3tQjA/AM3kHjr8KKNXf/e6Xtjacoo lPF5KF8PFxQVC6g2oy4+cBu4gGPbeiKYT+CAfzW1jEYKqqIeD9FuGrs6zzxwUaiqrkPI HOQkBgNOqKEX/pCfSqBU5TwA4BH476itttQFQcnFQRjez1en6L7FAN+wfYsiKbkrRl1h jXDJc38SGXPbY5HSzvLbO8LHKvshOeBkltUmwQ6zcOaWScgFrkpasGZ3rf12NLktvCef tJVl7OUCggSwOaKleKBz13fFGAy7n2Ufbky1AScnUlXVAcmREdJP6rPl25QJbJgddaFX +OlA== X-Gm-Message-State: AOAM532mHReASOT6XLQG01vhZiakugR5efbLCiHgbSwHNfSbzvrt+EMg ISMfUKOcRB92y5Vfx2t/7iR40oBYDrtx5PKYhpU= X-Google-Smtp-Source: ABdhPJyB+vyX38cWbUnLAqxLLS7Bz5vxxXU7XPBL9POtQtTCGVnRhEmf6VsPxdf4WSGYcGW3jrZFypWDBPzQsg0uk1Q= X-Received: by 2002:ab0:20d0:: with SMTP id z16mr40790617ual.33.1620958956781; Thu, 13 May 2021 19:22:36 -0700 (PDT) MIME-Version: 1.0 References: <20210513095433.GH1179226@tucnak> <20210513113704.GI1179226@tucnak> In-Reply-To: From: Hongtao Liu Date: Fri, 14 May 2021 10:27:04 +0800 Message-ID: Subject: Re: [PATCH] [i386] Fix _mm256_zeroupper to notify LRA that vzeroupper will kill sse registers. [PR target/82735] To: Jakub Jelinek , Uros Bizjak , Hongtao Liu , GCC Patches , "H. J. Lu" , Richard Sandiford Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_MANYTO, KAM_SHORT, 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, 14 May 2021 02:22:38 -0000 On Thu, May 13, 2021 at 7:52 PM Richard Sandiford wrote: > > Jakub Jelinek writes: > > On Thu, May 13, 2021 at 12:32:26PM +0100, Richard Sandiford wrote: > >> Jakub Jelinek writes: > >> > On Thu, May 13, 2021 at 11:43:19AM +0200, Uros Bizjak wrote: > >> >> > > Bootstrapped and regtested on X86_64-linux-gnu{-m32,} > >> >> > > Ok for trunk? > >> >> > > >> >> > Some time ago a support for CLOBBER_HIGH RTX was added (and later > >> >> > removed for some reason). Perhaps we could resurrect the patch fo= r the > >> >> > purpose of ferrying 128bit modes via vzeroupper RTX? > >> >> > >> >> https://gcc.gnu.org/legacy-ml/gcc-patches/2017-11/msg01325.html > >> > > >> > https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg01468.html > >> > is where it got removed, CCing Richard. > >> > >> Yeah. Initially clobber_high seemed like the best appraoch for > >> handling the tlsdesc thing, but in practice it was too difficult > >> to shoe-horn the concept in after the fact, when so much rtl > >> infrastructure wasn't prepared to deal with it. The old support > >> didn't handle all cases and passes correctly, and handled others > >> suboptimally. > >> > >> I think it would be worth using the same approach as > >> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg01466.html for > >> vzeroupper: represent the instructions as call_insns in which the > >> call has a special vzeroupper ABI. I think that's likely to lead > >> to better code than clobber_high would (or at least, it did for tlsdes= c). >From an implementation perspective=EF=BC=8C I guess you're meaning we shoul= d implement TARGET_INSN_CALLEE_ABI and TARGET_FNTYPE_ABI in the i386 backend. > > > > Perhaps a magic call_insn that is split post-reload into a normal insn > > with the sets then? > > I'd be tempted to treat it is a call_insn throughout. The unspec_volatil= e > means that we can't move the instruction, so converting a call_insn to an > insn isn't likely to help from that point of view. The sets are also > likely to be handled suboptimally compared to the more accurate register > information attached to the call: all code that handles calls has to be > prepared to deal with partial clobbers, whereas most code dealing with > sets will assume that the set does useful work, and that the rhs of the > set is live. > > Thanks, > Richard > --=20 BR, Hongtao