From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by sourceware.org (Postfix) with ESMTPS id 89B4B3852C58 for ; Mon, 21 Nov 2022 14:56:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 89B4B3852C58 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x1029.google.com with SMTP id e7-20020a17090a77c700b00216928a3917so14510253pjs.4 for ; Mon, 21 Nov 2022 06:56:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=YTokAWacfHwrPPOqlXx00VBgCHh/9VYb6x8UV4o89Rw=; b=FOMJb+gy/D9fxoABHHmsYrrZE1V5n3XPYpyWIPFy4IAnr3VEQ+EjSEELXb4lqOJWTE LVxxvPSEOXgP/1Y6x0W1rZvI/EZLgRxcQlbXO7uyLqdfap3WGz38CxMP/q0DY1fvJIiQ 6i4V/3bW5EkqsDObFDZ+xhcVq674i0vVbmXpkvwLJnJ91ZN5mchXlUe3LpTvKcfaBsUz bqpAT1G2cmpLk6zIgOLt889BMicsNjLol48q7oMcmdTxISUTlbsl6isXvfoxKvjGCntx OTsXG9DDtQnfDYjvUWk7yOS+hwOfkU39pI+DasBQcIIMrKEFIp1F4T6GxxZreIpa6hkY HOyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YTokAWacfHwrPPOqlXx00VBgCHh/9VYb6x8UV4o89Rw=; b=rAupNe2kI9/5F1w+Zeor95ResWjIWlGQR1YqWl8z6diYPNU/QCeeModgxpV7NHeZHT S/kpP3XQi0xH1lCnjg2K/s4IRSFZxw+Vy9NSt4RxdcYP5fvRTn2PlDZAnP33z+EC2mQI LbvKSjdwqLB/x/ALXVtDPluIQ2czpfAnJZueAtUhY7dVQFu4HGb/XZISWBFtQuiuS2pw DSWgTkt24EPdm14/kjXbVLD4GKpJEvV4zAVj82/2MVoDVECOw5XZpF9sPMCFQ1mV1J90 FEBBAYYXiOu/JeG+uwICUPN3wgHWFmSRx2p2FAZDI3WPYFupnN+KyKJ/xPZi3RMRWGF5 Ykpg== X-Gm-Message-State: ANoB5pnkR3GjpkmMVpo1gFAjHCvWtPoM+Y+0ohjyt/J6Uoiu3SN9v9I/ 38dci2w6O2+8pvzzZzdycqw= X-Google-Smtp-Source: AA0mqf4msnCX1Zt41lKpcRXGgttS4wryfS4H4dJbI8sj8Czf1td3o0+n76gdTBk0wlDp+HA0GlLgDA== X-Received: by 2002:a17:902:e80f:b0:188:f571:cea2 with SMTP id u15-20020a170902e80f00b00188f571cea2mr2437947plg.146.1669042575271; Mon, 21 Nov 2022 06:56:15 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id e12-20020a17090301cc00b001868981a18esm9970231plh.6.2022.11.21.06.56.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Nov 2022 06:56:14 -0800 (PST) Message-ID: Date: Mon, 21 Nov 2022 07:56:12 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH] riscv: implement TARGET_MODE_REP_EXTENDED Content-Language: en-US To: Alexander Monakov Cc: Philipp Tomsich , Vineet Gupta , gcc-patches@gcc.gnu.org, Kito Cheng , Jojo R References: <20220905214437.1275139-1-philipp.tomsich@vrull.eu> <05d1a70a-650b-b321-385e-eb1146587344@gmail.com> <1064b612-3826-4ee6-e47c-6f795fbcaab0@ispras.ru> From: Jeff Law In-Reply-To: <1064b612-3826-4ee6-e47c-6f795fbcaab0@ispras.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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 11/21/22 06:49, Alexander Monakov wrote: > 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). They're writing assembly code -- in my book that means they'd better have a pretty good understanding of the architecture, its limitations and quirks.  I'm happy to give them some diagnostics, guardrails, etc etc, but slowing down standard C code to placate someone who doesn't really know the architecture, but is trying to write assembly code is a step too far for me. > >> -- 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). Perhaps.  But it's also the case the LLVM and GCC have some significant differences in implementation.  Sometimes those differences in impementations have notable impacts on how code is generated. jeff > > Alexander