From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C2294385C6FA; Mon, 2 Oct 2023 07:48:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C2294385C6FA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1696232903; bh=ul5aHuyp0DWGaeQfYbOP6n+Gzs+gmOQ6ANn2YpLUTUs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MDTmVciRIgcQNRs0/WBh/Et0DOngtnCiDLA+1uwjoupCoVgCCF2nltsWP4pBLzDaw sMRo1LnADPZiTb2WYZiJ2FTlivKTxs6JQoNLmD/W5/K5e8p5frRksKzamoPPONDU/X pWCrQnDcZejAdrsKYg7j7EYfI+PgMPGDV8locxTk= From: "rdapp at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/111506] RISC-V: Failed to vectorize conversion from INT64 -> _Float16 Date: Mon, 02 Oct 2023 07:48:22 +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: 14.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rdapp at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED 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: cc 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D111506 Robin Dapp changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joseph at codesourcery dot= com --- Comment #3 from Robin Dapp --- I just got back. The problem with this is not -fno-trapping-math - it will vectorize just fi= ne with -ftrapping-math (and the vectorizer doesn't depend on it either). We = also already have tests for this in rvv/autovec/conversions. However, not all int64 values can be represented in the intermediate type i= nt32 which is why we don't vectorize unless the range of a[i] is know to be insi= de int32's range. If I'm reading the C standard correctly it says such cases = are implementation-defined behavior and I'm not sure we should work around the vectorizer by defining an expander that essentially hides the intermediate type. If that's an OK thing to do then I won't complain, though. CC'ing jmyers and rsandi because they would know best.=20=20 >From what I can tell aarch64 also does not vectorize this and I wonder why LLVM's behavior is dependent on -fno-trapping-math. We have the same issue with the reversed conversion from _Float16 to int64.= In that case trapping math is relevant, though, but we could apply the same lo= gic as in this patch and circumvent it by an expander. To me this doesn't seem right.=