From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) by sourceware.org (Postfix) with ESMTPS id 8A4033858C52 for ; Tue, 27 Sep 2022 19:39:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8A4033858C52 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-qv1-xf31.google.com with SMTP id w9so1019635qvn.11 for ; Tue, 27 Sep 2022 12:39:45 -0700 (PDT) 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; bh=EhuApF09OmyGmj1ooJj09kK+Cks/jtyjpIukz5QyWag=; b=fLI8VWqPZN5DEHictW3V2VcIaxQ8d4eXRCzvwzNG8oCNeIPx20EJa1KwD4pEAJRjxf Cauw481ky1ynGJJmLnFGkW6fxdH3s4oIysUVQYa7Jpem9irndWwMbiegN6phZUjaq67h mB0QJJCbj/7YXMN0Pj2SFSWhg2fwCbtLLlQwI4kEugA3WNmhI6MN1/kXpU42j/zaw0VY qbmIzX7VQ5IhKzN7BklU9DInKdvaeBmD8METIF0zXso9vtIMnWpDI8Xq4IElxb9jSowM adpjQ7njpaIi9RyBvKnrLJWvgB6byvtqT5C6oCyMVV7ttoDe5QzoMlFrKbkPX6gc4SvQ NTkw== 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; bh=EhuApF09OmyGmj1ooJj09kK+Cks/jtyjpIukz5QyWag=; b=O3hV9c3/yWyEf+VO43KZh4iFqz8779C3h6zd7n9y4XTEVuEeeKE2s5Ce5f8PGk5S3W 4xXRGHdIDCr4u6orxTDipICIQKbumXzmCsg10gFLt/WFJ39nCvbY3Pm5U5lGpCdeNSwQ vTFk0AxTzJUfCB03vs6reu2vq2bgTV2v3UKchBKVVy3H0doM4joIXP0EIAI/xGRbninG rsszhpEsXEmoPEv6OBdRKiutt9AH5ezuX3FGahivBOnjkpv/BxYpnsjOeATbrKtxaDtX g1p3UHJn7rWNVBuodzGFHy34wgWbI4hJV/pKMS4ilWrn5/tntArYZJ/UojKrZp6gwe4V r7gg== X-Gm-Message-State: ACrzQf0wvFxAYNhySL5BjuVmRswhPVQQKfw0o0p2zszTHCKWcuXHg/2F +hKfXRodwY/pasRO7IP6dV/dwWxXnpPhUvFj1oY= X-Google-Smtp-Source: AMsMyM64onLNHd0GQNbSqUmcs/C444AYqN87QmdLL0XAY4gtwLiF63jZnkZw5QDR+KetRafRnjQcpdIOBX21MQug7ns= X-Received: by 2002:a05:6214:d0e:b0:4ad:5e35:329a with SMTP id 14-20020a0562140d0e00b004ad5e35329amr22765190qvh.28.1664307584835; Tue, 27 Sep 2022 12:39:44 -0700 (PDT) MIME-Version: 1.0 References: <3b0984ef-c532-c29c-732a-1c9b569e134c@linux.ibm.com> <7ecca009-32ac-3b2f-e552-55414300113e@gmail.com> <70a54b9a-30ea-5673-3a41-9585b3abf627@linux.ibm.com> <5b687817-126e-d463-9d88-b3d7d2dad861@gmail.com> <7bd6cb29-a107-a7f2-463f-75bf811792a7@linux.ibm.com> In-Reply-To: <7bd6cb29-a107-a7f2-463f-75bf811792a7@linux.ibm.com> From: "H.J. Lu" Date: Tue, 27 Sep 2022 12:39:08 -0700 Message-ID: Subject: Re: [RFC] postreload cse'ing vector constants To: Robin Dapp Cc: Jeff Law , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3018.1 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 Tue, Sep 27, 2022 at 10:46 AM Robin Dapp via Gcc-patches wrote: > > > I did bootstrapping and ran the testsuite on x86(-64), aarch64, Power9 > > and s390. Everything looks good except two additional fails on x86 > > where code actually looks worse. > > > > gcc.target/i386/keylocker-encodekey128.c > > > > 17c17,18 > > < movaps %xmm4, k2(%rip) > > --- > >> pxor %xmm0, %xmm0 > >> movaps %xmm0, k2(%rip) > > > > gcc.target/i386/keylocker-encodekey256.c: > > > > 19c19,20 > > < movaps %xmm4, k3(%rip) > > --- > >> pxor %xmm0, %xmm0 > >> movaps %xmm0, k3(%rip) > > Before the patch and after postreload we have: > > (insn (set (reg:V2DI xmm0) > (reg:V2DI xmm4)) > (expr_list:REG_DEAD (reg:V2DI 24 xmm4) > (expr_list:REG_EQUIV (const_vector:V2DI [ > (const_int 0 [0]) repeated x2 > ]))))) > (insn (set (mem/c:V2DI (symbol_ref:DI ("k2")) > (reg:V2DI xmm0)))) > > which is converted by cprop_hardreg to: > > (insn (set (mem/c:V2DI (symbol_ref:DI ("k2"))) > (reg:V2DI xmm4)))) > > With the change there is: > > (insn (set (reg:V2DI xmm0) > (const_vector:V2DI [ > (const_int 0 [0]) repeated x2 > ]))) > (insn (set (mem/c:V2DI (symbol_ref:DI ("k2"))) > (reg:V2DI xmm0)))) > > which is not simplified further because xmm0 needs to be explicitly > zeroed while xmm4 is assumed to be zeroed by encodekey128. I'm not > familiar with this so I'm supposing this is correct even though I found > "XMM4 through XMM6 are reserved for future usages and software should > not rely upon them being zeroed." online. I opened: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107061 > Even inf xmm4 were zeroed explicity, I guess in this case the simple > costing of mov reg,reg vs mov reg,imm (with the latter not being more > expensive) falls short? cprop_hardreg can actually propagate the zeroed > xmm4 into the next move. > The same mechanism could possibly even elide many such moves which would > mean we'd unnecessarily emit many mov reg,0? Hmm... This sounds like an issue. -- H.J.