From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) by sourceware.org (Postfix) with ESMTPS id 22A9C385802F for ; Mon, 21 Nov 2022 13:49:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 22A9C385802F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ispras.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ispras.ru Received: from [10.10.3.121] (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTPS id 3B431419E9FF; Mon, 21 Nov 2022 13:49:37 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 3B431419E9FF Date: Mon, 21 Nov 2022 16:49:37 +0300 (MSK) From: Alexander Monakov To: Jeff Law cc: Philipp Tomsich , Vineet Gupta , gcc-patches@gcc.gnu.org, Kito Cheng , Jojo R Subject: Re: [PATCH] riscv: implement TARGET_MODE_REP_EXTENDED In-Reply-To: <05d1a70a-650b-b321-385e-eb1146587344@gmail.com> Message-ID: <1064b612-3826-4ee6-e47c-6f795fbcaab0@ispras.ru> References: <20220905214437.1275139-1-philipp.tomsich@vrull.eu> <05d1a70a-650b-b321-385e-eb1146587344@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-1881661990-1669038577=:4447" X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1881661990-1669038577=:4447 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Sun, 20 Nov 2022, Jeff Law wrote: > > The concern, as far as I understand would be the case where the > > assembly-sequence leaves an incompatible extension in the register. > > Right.  The question in my mind is whether or not the responsibility should be > on the compiler or on the developer to ensure the ASM output is properly > extended.  If someone's writing ASMs, then to a large degree, I consider it > their responsibility to make sure things are properly extended Right. They should also find out the hard way, with zero documentation telling them they had to (let alone *why* they had to), and without a hypothetical -fsanitize=abi that would catch exactly the point of the missing extension instead of letting the program crash mysteriously at a much later point. Uphill both ways, in a world where LLVM does not place such burden on the programmer, and even among GCC targets only mips64 made a precedent (also without documenting the new requirement). > -- even more so > if having the compiler do it results in slower code independent of ASMs. I think LLVM demonstrates well enough that a compiler can do a better job than GCC at eliminating redundant extensions without upgrading requirements for inline asm (in the usual C code, not for sub-word outputs of an asm). Alexander --8323328-1881661990-1669038577=:4447--