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 DBDC13857BAD for ; Mon, 7 Nov 2022 13:55:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DBDC13857BAD 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 1A72040D403E; Mon, 7 Nov 2022 13:55:31 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 1A72040D403E Date: Mon, 7 Nov 2022 16:55:31 +0300 (MSK) From: Alexander Monakov To: Philipp Tomsich cc: gcc-patches@gcc.gnu.org, Vineet Gupta , Kito Cheng , Jojo R Subject: Re: [PATCH] riscv: implement TARGET_MODE_REP_EXTENDED In-Reply-To: Message-ID: <4bc6d821-21d3-764c-269a-8f822257dd33@ispras.ru> References: <20220905214437.1275139-1-philipp.tomsich@vrull.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: On Sat, 5 Nov 2022, Philipp Tomsich wrote: > Alexander, > > I had missed your comment until now. Please make sure to read replies from Jeff and Palmer as well (their responses went to gcc-patches with empty Cc list): https://inbox.sourceware.org/gcc-patches/ba895f78-7f47-0f4-5bfe-e21893c4bcb@ispras.ru/T/#m7b7e5708b82de3b05ba8007ae6544891a03bdc42 For now let me respond to some of the more prominent points: > > I think this leads to a counter-intuitive requirement that a hand-written > > inline asm must sign-extend its output operands that are bound to either > > signed or unsigned 32-bit lvalues. Will compiler users be aware of that? > > I am not sure if I fully understand your concern, as the mode of the > asm-output will be derived from the variable type. > So "asm (... : "=r" (a))" will take DI/SI/HI/QImode depending on the type > of a. Yes. The problem arises when 'a' later undergoes conversion to a wider type. > The concern, as far as I understand would be the case where the > assembly-sequence leaves an incompatible extension in the register. Existing documentation like the psABI does not constrain compiler users in any way, so their inline asm snippets are free to leave garbage in upper bits. Thus there's no "incompatibility" to speak of. To give a specific example that will be problematic if you go far enough down the road of matching MIPS64 behavior: long f(void) { int x; asm("" : "=r"(x)); return x; } here GCC (unlike LLVM) omits sign extension of 'x', assuming that asm output must have been sign-extended to 64 bits by the programmer. Alexander