From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 83B943858C3A; Mon, 2 Oct 2023 18:35:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 83B943858C3A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1696271703; bh=SEPvhII2a+kOoYiaaMhHRHyGj7jHKcgj+XqODoOnsqY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bMmbgYjF5t9ePFmD0HAHQcsVbNHm7fNJLapDO+hfBHUhl+BPlJuKQjBEo599LGAxC +57A6+Sl1PSeDaDXPbRO1K9+WmMGtnPZsq5yfp+bVrfnzXPo3+Tz0VzOpAzT5yck8V DS4GiEV6drJ8Ahki8bW+wBBjb4BevUjuOQGiiUh0= 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 18:35:02 +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: 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 --- Comment #5 from Robin Dapp --- Ah, thanks Joseph, so this at least means that we do not need !flag_trapping_math here. However, the vectorizer emulates the 64-bit integer to _Float16 conversion = via an intermediate int32_t and now the riscv expander does the same just witho= ut the same restrictions. I'm assuming the restrictions currently imposed on two-step vectorizing conversions are correct. For e.g. int64_t -> _Float16 we require the value range of the source fit in int32_t (first step int64_t -> int32_t). For _Float16 -> int64_t we require -fno-trapping-math (first step _Float16 -> int32_t). The latter follows from Annex F of the C standard. Therefore, my general question would rather be: - Is it OK to circumvent either restriction by pretending to have an instruction that performs the conversion in two steps but doesn't actually = do the checks? I.e. does "implementation-defined behavior" cover the vectoriz= er checking one thing and one target not doing it? In our case the int64_t -> int32_t conversion is implementation defined when the source doesn't fit the target.=