From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by sourceware.org (Postfix) with ESMTPS id 2152A3858CDA for ; Tue, 8 Nov 2022 23:46:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2152A3858CDA Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu Received: by mail-lf1-x135.google.com with SMTP id b3so23386356lfv.2 for ; Tue, 08 Nov 2022 15:46:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tA2KjVaVLxQttFdYNNUIAk+yX9Wx4rzEJgZtyimUiW8=; b=Hp/AE8/KNpphjDmisLwD5nacXQJlqcjh+BS4ZMtFrckfeqUzfjBfFuCPrODlANyqjr +DH+TPdQx5V4VnpUK6KvOsp4/gucCkWyQmw0UaWKmTA8Mop1MCsjyy5ysTLg6GRHqkBo 7eC/J1Ufc0iMRBd9SWL+whmTTVsd8ZRGUWdujpwgo4TJ4x0Bcc7a7LxbxM+vDLi8fOAA xXdY18b5pFZ7Yt1MfRwghaMFLNzK0Rh6qWoOeI3Na9rw4bFLRsjvbzHP/Nkm6Y6rcyA2 Q2biEsSYZfMdLtpFR7sAZ6+KyLgC/X0FghhDccYq8MeNYvMS0RBn0W2zrYbZE1oES0BV 1ufw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tA2KjVaVLxQttFdYNNUIAk+yX9Wx4rzEJgZtyimUiW8=; b=WuLzY8zXmAEo42Dml0Rwqhzmq8GVvJVYV716XSrwtJyOb4WKpXR7UrSTHM79TDJKBm hS80YIjgOE+22SNQET1wSz3+rTQn0KQfUaidHLh2Nif4cda5py+gr1w951eOfmA2+Oyv 7df6Wrg7tqb9pPcJeIKtanhyEnhdEqvnErilKJ03aYYwAkbrNL6+qvQOUIs5PuflltOM FXH3NddoYlNyfek+mejgotiO06hljmzYhF8h3tKimja+QodtHkRG1ARNWj27ha/IQHOl OCpdS4EPvQrE/4BdruikPbrtfsZ6SFn0YwWWlHFQvD6GgjRA5ZOIlpdC/JfKlAjTYayB /opw== X-Gm-Message-State: ACrzQf2VKA9A9zLcQgMFfuD/NTtjlX3oKLK0EBwSn7r4vDWxrDfS4mB7 buNh/TlsFHVywcvgu4ds6mRnCaWX1Z0Tf9b+13AUjA== X-Google-Smtp-Source: AMsMyM7McEuuPpDx4H8L2689csggM7ASqa0zjKZ0m3+WMpj4nUxe5lB9GkvSgKmXUUo3yxlauHEhiCKet8HYlHRAOW8= X-Received: by 2002:a05:6512:25d:b0:4a2:6e28:5d43 with SMTP id b29-20020a056512025d00b004a26e285d43mr19156528lfo.10.1667951159515; Tue, 08 Nov 2022 15:45:59 -0800 (PST) MIME-Version: 1.0 References: <20220905214437.1275139-1-philipp.tomsich@vrull.eu> <4bc6d821-21d3-764c-269a-8f822257dd33@ispras.ru> In-Reply-To: <4bc6d821-21d3-764c-269a-8f822257dd33@ispras.ru> From: Philipp Tomsich Date: Wed, 9 Nov 2022 00:45:48 +0100 Message-ID: Subject: Re: [PATCH] riscv: implement TARGET_MODE_REP_EXTENDED To: Alexander Monakov Cc: gcc-patches@gcc.gnu.org, Vineet Gupta , Kito Cheng , Jojo R , Jeff Law Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 Mon, 7 Nov 2022 at 14:55, Alexander Monakov wrote: > > > > 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. In fact, with the proposed patch (but also without it), GCC will sign-extend: f: sext.w a0,a0 ret .size f, .-f To make sure that this is not just an extension to promote the int to long for the function return, I next added another empty asm to consume 'x'. This clearly shows that the extension is performed to postprocess the output of the asm-statement: f: # ./asm2.c:4: asm("" : "=r"(x)); sext.w a0,a0 # x, x # ./asm2.c:5: asm("" : : "r"(x)); # ./asm2.c:7: } ret Thanks, Philipp.