From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id C502C38582AD for ; Fri, 16 Sep 2022 23:48:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C502C38582AD 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-pg1-x530.google.com with SMTP id t65so21738251pgt.2 for ; Fri, 16 Sep 2022 16:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=I/7LxDXChWBdFKKbpdLR0wSyWRjT+AnKFfF5Df7pkvM=; b=PRkhL1IhG21iaNxiT5OZn+wo9NscKj73noxXiYFmE1HCz3rhIUD7XwhSmqUvgh3h8u DDzYpkj4SttQWMAWQ3zxN4GbpPj/AP1s+ug5JoBZzCV0m03o0dwyBm76HLbyeADClhP2 y0qAz+fyzjdCqFn9wGS17Eh0V6S4B9LCnauF447pjTjFMYHg4dGZcvySU8Oq9Hc5ieJW O0fQ9YtGFzLvfKBV2metz2ZXvKUMgQ8t49ZhYQN9/0GYRF1FdukgRio+CIx1clrjYymh KTUsVN1UaiygOlravZAKe9b7z42MCfCljXGAt1SsdLlFUZ8fMcx5BMWl9INeLsDvD+3m vCXw== 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:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=I/7LxDXChWBdFKKbpdLR0wSyWRjT+AnKFfF5Df7pkvM=; b=necSXL7e9oW956lU6uLvp+ue8S2NvLmEDoEIHx/nwCC9OLklQ0ULN4u92akI/tyGNp WbwW6lAJT/ZlTmqRIENHC1l4vqHKot7IQyvpNJ0xbPfKj2ijXqyFJTdvh1j3VMYoGS3C L6Uj6qAQM92SrwSVUC+l6lmzwZ7D1gWvTkInOCjQryB0Gy8UgS7C8Hs6q5Ubfd/sUw7E 57u6ml+UmO6icP6gf55gbwRcPFizNAMqbWO6IGDVSeKhCQpuqe+raQ+PgtqMIvpWwpgm pElDoatIkIRr4Rk6RlHDVL3hq4hnvIOyR66E0YzqLAfv3q11KdOMpfBmt+wAOgnygGT2 RT3g== X-Gm-Message-State: ACrzQf3dLEBcrgjIOt6RT0IlLz2C3++r59bRQK5G727hv0AolzqwfcJT noVFDs+qBIcKFrnA9kkPQGtxhlqk9oixEA== X-Google-Smtp-Source: AMsMyM7G9aWsdNuMKm0m1+yZRfR0Q9zaYwbVivv23oDKSe1n7lVCgPU0ZURCN7WqPlf9+rJBRfqLCw== X-Received: by 2002:a63:b957:0:b0:434:c30d:84b0 with SMTP id v23-20020a63b957000000b00434c30d84b0mr6653600pgo.293.1663372106188; Fri, 16 Sep 2022 16:48:26 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id o4-20020a170902bcc400b00177ee563b6dsm15439126pls.33.2022.09.16.16.48.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Sep 2022 16:48:25 -0700 (PDT) Message-ID: <4d4edef0-8a44-d6b8-0f50-1abd7f5e91f4@gmail.com> Date: Fri, 16 Sep 2022 17:48:24 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [PATCH] riscv: implement TARGET_MODE_REP_EXTENDED Content-Language: en-US To: gcc-patches@gcc.gnu.org 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=-3.3 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 9/6/22 05:39, Alexander Monakov via Gcc-patches 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? Is this significantly different than on MIPS?  Hand-written code there also has to ensure that the results are properly sign extended and it's been that way for 20+ years since the introduction of mips64 IIRC.  Though I don't think we had MODE_REP_EXTENDED that long. Haha, MIPS is the only target that currently defines TARGET_MODE_REP_EXTENDED :-) > > Moreover, without adjusting TARGET_TRULY_NOOP_TRUNCATION this should cause > miscompilation when a 64-bit variable is truncated to 32 bits: the pre-existing > hook says that nothing needs to be done to truncate, but the new hook says > that the result of the truncation is properly sign-extended. > > The documentation for TARGET_MODE_REP_EXTENDED warns about that: > > In order to enforce the representation of mode, TARGET_TRULY_NOOP_TRUNCATION > should return false when truncating to mode. This may well need adjusting in Philipp's patch.   I'd be surprised if the MIPS definition wasn't usable nearly verbatim here. jeff