From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) by sourceware.org (Postfix) with ESMTPS id 075253857343 for ; Mon, 30 May 2022 08:28:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 075253857343 Received: by mail-qk1-x72e.google.com with SMTP id b200so10826008qkc.7 for ; Mon, 30 May 2022 01:28:29 -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=ylR0IqjXndpFhqSZBn9nwRq99uMYr/Nsoyr5dciCqdw=; b=ZnrIstA/K6zorzD4NGN8QJaeMR5ZYp2N5mrBg98jC4xNG25AaAtRHbgJwxmz0ZfpV6 f5hd41YgFPhUnsmOHlfmWTHj0Q5ZhQ527PFVrHFJwh2qWULA/63EaABPxAB4LMWuP0tt gcFysPNsx1ND9Ul7vQzySPKFqU6t9L6KpaULfaWZ2X156tvaAjVRkXhI6XpYCNe/V/Yo LnpOfmxQAT+X1sNw5MbSW4r12eHWQI7Pyv0XZXh5D4ws7VrmRpuSgj3g7F8jc2KaZbLq rRtCOIhzdG4B/aqAfWXuv6TR9SLo1F9De0eKH9mqFbIyd5VsJsDvcuqFD7LuoE4AKyQr PocQ== X-Gm-Message-State: AOAM533/IqowQExmn3Wpn94+wWOjzjouH2/cNBHFyVi/yY/HDzjIlwkY wSbHkhdRf889m1WSx217j+qhwzC2lBTsFklm23U= X-Google-Smtp-Source: ABdhPJz0zhFe+Iitb5ssTWLnqY8AKQMKXOBqAzZT0utHSJgIQpOvqvUENRSlZSC7074tSJXosfLNIm5sn6OJH4j8iWQ= X-Received: by 2002:a05:620a:4403:b0:6a5:9b36:b49e with SMTP id v3-20020a05620a440300b006a59b36b49emr17290513qkp.674.1653899308335; Mon, 30 May 2022 01:28:28 -0700 (PDT) MIME-Version: 1.0 References: <20d007c8-f703-8fac-6a13-1643af31adc6@suse.com> <8f3b668c-4701-aed6-716b-94773c4fcedb@suse.com> In-Reply-To: <8f3b668c-4701-aed6-716b-94773c4fcedb@suse.com> From: Uros Bizjak Date: Mon, 30 May 2022 10:28:17 +0200 Message-ID: Subject: Re: [PATCH] x86: {,v}psadbw have commutative source operands To: Jan Beulich Cc: "gcc-patches@gcc.gnu.org" , "hubicka@ucw.cz" , Kirill Yukhin , Hongtao Liu Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.8 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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 30 May 2022 08:28:35 -0000 On Mon, May 30, 2022 at 9:59 AM Jan Beulich wrote: > > On 27.05.2022 11:05, Uros Bizjak wrote: > > On Fri, May 27, 2022 at 10:13 AM Jan Beulich wrote: > >> > >> Like noticed for gas as well (binutils-gdb commit c8cad9d389b7), the > >> "absolute difference" aspect of the insns makes their source operands > >> commutative. > > > > You will need to expand via ix86_fixup_binary_operands_no_copy, use > > register_mmxmem_operand on both input operands and use > > ix86_binary_operator insn constraint. Please see many examples w/ > > commutative operands throughout .md files. > > Hmm, yes, I see. As to the use of ix86_binary_operator_ok(): In > particular in sse.md I see many uses of > ix86_fixup_binary_operands_no_copy() in expanders where the > corresponding insns don't use ix86_binary_operator_ok(), e.g. the > immediately preceding uavg. Is there a(n) (anti-)pattern? ix86_fixup_binary_operands was historically used with destructive two-operand instructions (where one input operand is tied with output operand). It fixed up expansion to help register allocator a bit, and brought expansion to the form of two-operand instruction, especially with memory and immediate operands. Please note that nowadays RA can fix up the operands by itself, but it is still beneficial to have e.g. memory operation in the right place from the beginning. > My simplistic initial version was based on observations while > putting together the inverse change for > vgf2p8affine{,inv}qb_ (commit c0569d342ca4), which > aren't commutative. Are you suggesting that the remaining (for indeed > being commutative) vgf2p8mulb_ also is incomplete, > requiring an expander as well? And maybe the same then in > v1ti3 for any_logic:V1TI, avx512bw_umulhrswv32hi3, > or _dp (and likely a few more)? > > At least a few pmadd* appear to lack commutativity marking altogether. Yes, sse.md could use some TLC in this area. I remember doing a review of these patterns in i386.md a while ago. Uros. > Jan > > >> --- a/gcc/config/i386/mmx.md > >> +++ b/gcc/config/i386/mmx.md > >> @@ -4407,7 +4407,7 @@ > >> > >> (define_insn "mmx_psadbw" > >> [(set (match_operand:V1DI 0 "register_operand" "=y,x,Yw") > >> - (unspec:V1DI [(match_operand:V8QI 1 "register_operand" "0,0,Yw") > >> + (unspec:V1DI [(match_operand:V8QI 1 "register_operand" "%0,0,Yw") > >> (match_operand:V8QI 2 "register_mmxmem_operand" "ym,x,Yw")] > >> UNSPEC_PSADBW))] > >> "(TARGET_MMX || TARGET_MMX_WITH_SSE) > >> --- a/gcc/config/i386/sse.md > >> +++ b/gcc/config/i386/sse.md > >> @@ -19983,7 +19983,7 @@ > >> (define_insn "_psadbw" > >> [(set (match_operand:VI8_AVX2_AVX512BW 0 "register_operand" "=x,YW") > >> (unspec:VI8_AVX2_AVX512BW > >> - [(match_operand: 1 "register_operand" "0,YW") > >> + [(match_operand: 1 "register_operand" "%0,YW") > >> (match_operand: 2 "vector_operand" "xBm,YWm")] > >> UNSPEC_PSADBW))] > >> "TARGET_SSE2" > >> > > >