From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 0B38B3858C83; Wed,  9 Feb 2022 19:06:38 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0B38B3858C83
From: "law at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/97040] incorrect fused multiply add/subtract instruction
 generated from C code
Date: Wed, 09 Feb 2022 19:06:38 +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: 8.2.1
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: law at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: law at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-97040-4-IZcT8MH3fR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-97040-4@http.gcc.gnu.org/bugzilla/>
References: <bug-97040-4@http.gcc.gnu.org/bugzilla/>
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 <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Feb 2022 19:06:39 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97040

--- Comment #2 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So a bit more background.  I was doing some maintenance work on the v850 a =
few
years back and noticed an issue with e3v5 testing and FMAs.  I poked around=
 a
bit and had largely ruled out the generic bits of FMA generation as the
problem.  But I was very short of time and didn't have reasonable docs on t=
he
implementation of FMAs for the newer versions of the v850 (e3v5 was added l=
ong
after I did the original port).  Renesas's site isn't great for finding the
relevant docs as you have to map from something like e3v5 to a part within =
the
v850 family:(

SO I set it aside.  You report caused me to dig a bit further.  I finally f=
ound
a mapping from e3v5 to a specific part on Renesas's site (RH850G3KH) and was
able to review the specification of these instructions.

Again I managed to convince myself that our gimple FMA generation was corre=
ct.=20
I also convinced myself that the RTL patterns for the v850 match the
documentation from Renesas.   Then it finally hit me.

The v850 patterns are using pattern names that require specific semantics. =
 ie,
if the expanders see a pattern fnma<mode> they expect that pattern will
implement very specific semantics.  In particular they expect that the nega=
tion
will apply to one of the arguments to the multiplication.   But the instruc=
tion
emitted in those patterns negates the final result.  ie, GCC expects this
semantic from the fnma<mode> pattern

  (fma (neg op0) (op1) (op2))

But the v850 chip implements

  (neg (fma (op0) (op1) (op2)))

So the bug is using the "fnma" and "fnms" names for those patterns.  The RT=
L is
fine, it's strictly a pattern naming issue.=