From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) by sourceware.org (Postfix) with ESMTPS id CB4AA3858425 for ; Fri, 23 Dec 2022 07:23:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CB4AA3858425 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-yw1-x112c.google.com with SMTP id 00721157ae682-417b63464c6so56449737b3.8 for ; Thu, 22 Dec 2022 23:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=j6VTifOFbh+TfSUnbxOzbJRL4wuFrxf5xwen9nJS9O8=; b=MHce9T/HBRQcrij3t1+ZgbwZlfYuHVUG6TfMY0r47S2s+TROCN6nhRY3I6b9I7IuWg uOxXpOCL8paPKw+yh4VK5ftbVVC1RAhkCkgRGFlIF/NAwiCNYEQBK0iXGImM0r6X6fy9 8WPuJqALgWebG4yhQ7UN+McLE/JjftcwqbBE9kiKYrVenJOUQvkxXWnrj2Ux517qdHGx vnWZrGXcavDnYh7yhmrAqhOH2KUwk+0gLyWLp25nSyGJqta2TBHDfZqfEYVPFn1jE4nL EuO6vodbpOy3dCiD6cDGmFc5dBwQgwfEaMKU8cTz4IOBBoOdCpWACgKoEEFQVPOcpj8n WeNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=j6VTifOFbh+TfSUnbxOzbJRL4wuFrxf5xwen9nJS9O8=; b=Ba7APv8G0ZtOyWg6xGGSavEDAILTV2SkMcL92P3fpyR28l4UfyPfxecaIw8p/wyJzS WiGr/5SvWKw4VXKLb8vAW7iNc2ZFykwwVitloSD8OSbLI1EfwSe9DnJCxxrVBWrnkqGO pWyVJmwIbwnNAXxFMqQ/DMtAW7UzlYi4ePmG9grc/Fv8VKxXRyemQD8FxmOSP8eldQ7L CVtOX26y8AgBUEOVMdGGYh9pYuUVr5RgSUQT41Po2VwYPwEgmuZbwt4KgQ6LzIHHlmrk w5ngDO/LOWY0i1BUAlOt05F15/eXubq+4FLODHWUIUUCNvhn3Niv0h+U4WIpIp9ngs5j xwPQ== X-Gm-Message-State: AFqh2kp0YWQNZb1xZJQ4mSqDNzAtQiS2EZKctHkJd8AyRZvEZOBPI/0h H+EK4giodGAjEW+P2BLPj4Gs0TMttAsERY64NVQ= X-Google-Smtp-Source: AMrXdXt2g5HtWEy416RwZ8RoFlc9ujWD19aqDaRkM9aiuMM5V701f3x3El0emBaBNcohwi6YpJbvN/Z5/OMpC+RpgjE= X-Received: by 2002:a81:55c9:0:b0:38e:8263:755a with SMTP id j192-20020a8155c9000000b0038e8263755amr1007355ywb.480.1671780193907; Thu, 22 Dec 2022 23:23:13 -0800 (PST) MIME-Version: 1.0 References: <001001d9165a$73e9cc30$5bbd6490$@nextmovesoftware.com> In-Reply-To: <001001d9165a$73e9cc30$5bbd6490$@nextmovesoftware.com> From: Uros Bizjak Date: Fri, 23 Dec 2022 08:23:03 +0100 Message-ID: Subject: Re: [x86 PATCH] PR target/106933: Limit TImode STV to SSA-like def-use chains. To: Roger Sayle Cc: GCC Patches , "H.J. Lu" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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 Fri, Dec 23, 2022 at 12:09 AM Roger Sayle wrote: > > > With many thanks to H.J. for doing all the hard work, this patch resolves > two P1 regressions; PR target/106933 and PR target/106959. > > Although superficially similar, the i386 backend's two scalar-to-vector > (STV) passes perform their transformations in importantly different ways. > The original pass converting SImode and DImode operations to V4SImode > or V2DImode operations is "soft", allowing values to be maintained in > both integer and vector hard registers. The newer pass converting TImode > operations to V1TImode is "hard" (all or nothing) that converts all uses > of a pseudo to vector form. To implement this it invokes powerful ju-ju > calling SET_MODE on a REG_rtx, which due to RTL sharing, often updates > this pseudo's mode everywhere in the RTL chain. Hence, TImode STV can only > be performed when all uses of a pseudo are convertible to V1TImode form. > To ensure this the STV passes currently use data-flow analysis to inspect > all DEFs and USEs in a chain. This works fine for chains that are in > the usual single assignment form, but the occurrence of uninitialized > variables, or multiple assignments that split a pseudo's usage into > several independent chains (lifetimes) can lead to situations where > some but not all of a pseudo's occurrences need to be updated. This is > safe for the SImode/DImode pass, but leads to the above bugs during > the TImode pass. > > My one minor tweak to HJ's patch from comment #4 of bugzilla PR106959 > is to only perform the new single_def_chain_p check for TImode STV; it > turns out that STV of SImode/DImode min/max operates safely on multiple-def > chains, and prohibiting this leads to testsuite regressions. We don't > (yet) support V1TImode min/max, so this idiom isn't an issue during the > TImode STV pass. > > For the record, the two alternate possible fixes are (i) make the TImode > STV pass "soft", by eliminating use of SET_MODE, instead using replace_rtx > with a new pseudo, or (ii) merging "chains" so that multiple DFA > chains/lifetimes are considered a single STV chain. I assume these two alternatives would result in much more invasive surgery, so let's consider these "for the future". > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > and make -k check, both with and without --target_board=unix{-m32}, > with no new failures. Ok for mainline? > > > 2022-12-22 H.J. Lu > Roger Sayle > > gcc/ChangeLog > PR target/106933 > PR target/106959 > * config/i386/i386-features.cc (single_def_chain_p): New predicate > function to check that a pseudo's use-def chain is in SSA form. > (timode_scalar_to_vector_candidate_p): Check that TImode regs that > are SET_DEST or SET_SRC of an insn match/are single_def_chain_p. > > gcc/testsuite/ChangeLog > PR target/106933 > PR target/106959 > * gcc.target/i386/pr106933-1.c: New test case. > * gcc.target/i386/pr106933-2.c: Likewise. > * gcc.target/i386/pr106959-1.c: Likewise. > * gcc.target/i386/pr106959-2.c: Likewise. > * gcc.target/i386/pr106959-3.c: Likewise. OK. Thanks, Uros.