From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) by sourceware.org (Postfix) with ESMTPS id 544983858415 for ; Wed, 8 Sep 2021 09:55:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 544983858415 Received: by mail-vs1-xe32.google.com with SMTP id bf15so1534429vsb.0 for ; Wed, 08 Sep 2021 02:55:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BoNv/DlHaQCYRK2U0lPMhUx+eyeQoLWMQ8xDlL1vP70=; b=Dt8cUkQY1482+swkrXjNAv2N8v//0MmePtHnWgGx3JRU+cz21fOgSQDqyZhBlspXPl Wai1PVbaakaTtH19bwExkG+/J5NaSqSX78miBEmF9s6Spz349U1XvFWJKHjE040Ic5Gz cidowGOpF4oW0R64amw5UXyod/hQUf0wzIDekHWeI/Go+lntfS0E7Z1AZUzlDI3L7yLg iYgQ9AYD9Y7lJM59KcsAUE2l8WmvRyZtdGWblZjQOo0L4MyQscJPSxJ+fohnAwwK4BSE PSuisrcrgQ5VmVtDcxuV/A5mhqmYf/FwBDY0q8RNjkUux7ODWQf0N0Cmw/wqHtB88ctz 42XA== X-Gm-Message-State: AOAM531CcEIxngjKNwjMI23sYNHKCh+UCD9h8aTPHZd/B+4uxtjGHdSe +re8l4EKkx5QSwQy/Y+eArmn2xDzI+ze+jvoWoA= X-Google-Smtp-Source: ABdhPJwZe2WEyZbxGjiZHAsh9Om/mGrhB+rN+EgCiFMMczJWEvi5bIgP+bzaSkCoCCy5m+r6hqlM4h1LsFm2KGVqKpU= X-Received: by 2002:a67:f243:: with SMTP id y3mr1431363vsm.33.1631094913958; Wed, 08 Sep 2021 02:55:13 -0700 (PDT) MIME-Version: 1.0 References: <20210908074250.GO920497@tucnak> <20210908093337.GR920497@tucnak> In-Reply-To: <20210908093337.GR920497@tucnak> From: Hongtao Liu Date: Wed, 8 Sep 2021 18:00:50 +0800 Message-ID: Subject: Re: [PATCH] i386: Fix up @xorsign3_1 [PR102224] To: Jakub Jelinek Cc: Uros Bizjak , liuhongt , "H.J. Lu" , GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.0 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Wed, 08 Sep 2021 09:55:15 -0000 On Wed, Sep 8, 2021 at 5:33 PM Jakub Jelinek wrote: > > On Wed, Sep 08, 2021 at 05:23:40PM +0800, Hongtao Liu wrote: > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > > > > Patch LGTM. > > Thanks, committed. > > > PS: > > I'm curious why we need the post_reload splitter @xorsign3_1 > > for scalar mode, can't we just expand them into and/xor operations in > > the expander, just like vector modes did. > > Let me do some experiments to see whether it is ok to remove the splitter. > > I bet it is the question how should the code look like before RA. > stv is somewhat related, but as that replaces whole chains, it can do: > (insn 14 5 6 2 (set (subreg:V2DI (reg:DI 92) 0) > (vec_concat:V2DI (mem/c:DI (symbol_ref:SI ("c") [flags 0x2] ) [1 c+0 S8 A64]) > (const_int 0 [0]))) "hohohou.c":6:9 -1 > (nil)) > on loads of memory. > But it stv still does use paradoxical subregs: > (insn 10 16 11 2 (set (subreg:V2DI (reg:DI 91) 0) > (minus:V2DI (subreg:V2DI (reg:DI 87) 0) > (subreg:V2DI (reg:DI 94) 0))) "hohohou.c":6:13 5003 {*subv2di3} > (expr_list:REG_DEAD (reg:DI 87) > (expr_list:REG_UNUSED (reg:CC 17 flags) > (nil)))) > (insn 11 10 0 2 (set (mem/c:DI (symbol_ref:SI ("a") [flags 0x2] ) [1 a+0 S8 A64]) > (reg:DI 91)) "hohohou.c":6:5 76 {*movdi_internal} > (expr_list:REG_DEAD (reg:DI 91) > (nil))) > so perhaps just using paradoxical subregs everywhere would be ok? Yes, I think so. And I find paradoxical subreg like (subreg:V4SF (reg:SF)) are not allowed by validate_subreg until r11-621. That's why post_reload splitter is needed here. > Jakub > -- BR, Hongtao