From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 473673898383 for ; Sun, 20 Nov 2022 16:09:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 473673898383 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-pl1-x630.google.com with SMTP id y10so7363031plp.3 for ; Sun, 20 Nov 2022 08:09:09 -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=xDJalhwq/NLtOf/tYnRskkM0U3IlYdYXvTn7qmNQDj0=; b=lZr5H8AMmueRtjdpbTCxjp3wnZdxF1H2UZrrw7V7ON0bySscgKt6YWoN4O+8kXbbFu eP5ERrMyYQRIQC2hYrPbYi02OVVmesMf/EFPYLk36q2O/8nVuLawPGMk0ATG+I5plXjZ wwWo2bdIYI/T7QkXUjHifhaApJmyOy6WN0zAyM8WJpHOVX/Pq8pYPsCI2C8I4Kxox7Mj L02D/Jq+CYUOB1iJiKob/rnwsQZfL23IpPCAQ77cUmtY4v0OOM+7+tRAe3eBmgLgy+bA 6J1OR+E90DsZduq6EXx0jXwFgkWK/T8AkR5oIUiI7KlL3IA2ThbL7ZZRPPycnc/NTD03 a50Q== 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=xDJalhwq/NLtOf/tYnRskkM0U3IlYdYXvTn7qmNQDj0=; b=GfxHdGQP7hG2Xjl/43IdtyhVMC8DdFyBmzWv/K/AYGAvkkfrpYbKz+ZFx1u3VRALHd pbw+F+KHtargAagHHOIPQUjTDXgDPee6eccEXZBPzUd6w1/bZ16e/NOeXnkcRJ/XK+qM Rv4mh19rtZwPoB0Xf9HM0t9t/emHzM15AagEwUJnT+qjCR2dWzoahK7domW5H1N1LfRN PFsCRPqcgMQsZAh8hb7wAQUYIUuVSR4hwKbD+IQyz7vdxZXZJEvdQJ0K8Eqs4UTJD6L5 bjNmUj4JCas9uM5rZUeSwsIMNpilGNPdEawM7fme59BF5L9/Xk+JZBZyyyYNIvDMpLzh 3KAA== X-Gm-Message-State: ANoB5pmjp21xdbGcXTxaIh5FSct5fGmTlZV+aLF0jxWwlrVg9v7qyqNg jZ7D+CSdjFPQqk9J19eHgIE= X-Google-Smtp-Source: AA0mqf43NlHDrNp9TTTU5ituhRoQgIFZhvwx14/IgdvX2SBr/jtMXlgVMvWxLFzkDntoWBHCzmbw3Q== X-Received: by 2002:a17:90a:5c85:b0:20a:92d2:226a with SMTP id r5-20020a17090a5c8500b0020a92d2226amr5140807pji.155.1668960547950; Sun, 20 Nov 2022 08:09:07 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id b8-20020a1709027e0800b0016c0c82e85csm7644640plm.75.2022.11.20.08.09.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 20 Nov 2022 08:09:07 -0800 (PST) Message-ID: <05d1a70a-650b-b321-385e-eb1146587344@gmail.com> Date: Sun, 20 Nov 2022 09:09:05 -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: Philipp Tomsich , Alexander Monakov Cc: Vineet Gupta , gcc-patches@gcc.gnu.org, Kito Cheng , Jojo R References: <20220905214437.1275139-1-philipp.tomsich@vrull.eu> From: Jeff Law In-Reply-To: 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/4/22 17:00, Philipp Tomsich wrote: > Alexander, > > I had missed your comment until now. > > On Tue, 6 Sept 2022 at 13:39, Alexander Monakov wrote: >> On Mon, 5 Sep 2022, Philipp Tomsich wrote: >> >>> +riscv_mode_rep_extended (scalar_int_mode mode, scalar_int_mode > mode_rep) >>> +{ >>> + /* On 64-bit targets, SImode register values are sign-extended to > DImode. */ >>> + if (TARGET_64BIT && mode == SImode && mode_rep == DImode) >>> + return SIGN_EXTEND; >> 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. Correct. > > 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 -- even more so if having the compiler do it results in slower code independent of ASMs. Jeff