From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 07A413939C02; Thu, 17 Jun 2021 12:07:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 07A413939C02 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/87555] There is no need for UNSPEC_FMADDSUB Date: Thu, 17 Jun 2021 12:07:46 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: everconfirmed bug_status cf_reconfirmed_on Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 12:07:47 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D87555 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed| |2021-06-17 --- Comment #1 from Richard Biener --- The complication is that the define_insn looks like (define_insn "*fma_fmaddsub_" [(set (match_operand:VF_128_256 0 "register_operand" "=3Dv,v,v,x,x") (unspec:VF_128_256 [(match_operand:VF_128_256 1 "nonimmediate_operand" "%0,0,v,x,x") (match_operand:VF_128_256 2 "nonimmediate_operand" "vm,v,vm,x,m") (match_operand:VF_128_256 3 "nonimmediate_operand" "v,vm,0,xm,x"= )] UNSPEC_FMADDSUB))] "TARGET_FMA || TARGET_FMA4" "@ vfmaddsub132\t{%2, %3, %0|%0, %3, %2} vfmaddsub213\t{%3, %2, %0|%0, %2, %3} vfmaddsub231\t{%2, %1, %0|%0, %1, %2} vfmaddsub\t{%3, %2, %1, %0|%0, %1, %2, %3} vfmaddsub\t{%3, %2, %1, %0|%0, %1, %2, %3}" so it can handle the {132,213,231} variants without much duplication from a single pattern. But it seems this cannot prevail when we open-code the operation. Likewise handling multiple modes with the VF_128_256 iterator becomes difficult since the addsub requires either a vec_merge (as in the addsub patterns) with a constant selector specific to the mode (unless we can provide a large one that is implicitely truncated) or a vector constant when using the (vec_select (vec_concat ...)) form. So the above would split into 12 somewhat repetitive patterns. Doable. Repeat for the AVX512 ones. Tedious ;)=