From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id 0C4363835549 for ; Sat, 17 Sep 2022 07:59:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0C4363835549 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-ej1-x62e.google.com with SMTP id go34so54068087ejc.2 for ; Sat, 17 Sep 2022 00:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from :in-reply-to:subject:date:from:to:cc:subject:date; bh=T2SAUTiPzfOy9CIKUk8Gw6fXFZ4chdvV1hVWbX+ZXrc=; b=ZNxcTy5hNx+D57B6vHBRgx7DMSRXxzYGCU1aT+jSeu/psaj/kuTLlZqdNja+jZr2Jb IEHO6hx0GYlZGp8FimYomA9UlS71+lzzcOo6Cd2gat0gT8fCpap3wSx3xzox1ODlAH4H Zs5/Cz8ONvHIVFBYNeLs07dRChNWGbF84ZnooqjqI2EplB3WejXxGbQttt5Z7iYgbzx2 YqKbk/NbmoioIjV7DydufxCQRmEF9CMdVkiWZzyfx1Dx+SoYgWMu4qH0qc8B0yrZtr9T VhQ9KSY6s/EiNmUYjGvrFjXlMmsPrUN/Me6JgvSCJajtj1F2a+rSn6GpMzqq/8aZCeGa YQQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date; bh=T2SAUTiPzfOy9CIKUk8Gw6fXFZ4chdvV1hVWbX+ZXrc=; b=jdT7HORiQdylJ8qohUlrmtNiMs0+jtKEfc6Fl5Xv5GZk3u/rQ7Rc6ld5LExShxid9C nFaeg7CV5tA75HjyDr0W2E2dKreBH02h7z6Sc86a+deUKS/tB78by4+d36qgrEfnK5XI 7y629FHin8tM4Exq2Yv3XW9kkts05KHU1ZZoFz2tVIAZ2ET733rC9N3k6NZQpmSDoYfc /gkuTYMV1/O9VcbwRPgfNd40v+iI4VgRn16px1ADMYTVMGpbTpZBYC5ensJGrgJXw4Qm qT3kGe2l2YvwzTDsnN5M0N2j7ch2cduKyKLbe/O4cJmKGLFMTnLuMAH/W+CJ8oomRxWP WZgw== X-Gm-Message-State: ACrzQf1+3CY8qqNWBKPSGoPoRLn42pztRZ2fhi0D97ueFqZqu58u/LeT TB8SVT0Z/gzx6YCsX6LIsv3BMkE6eauGBoxMXd30ZA== X-Google-Smtp-Source: AMsMyM5swMBCIT0Zoa/tUhAQRo6LkN/ibBBkC78C/FFcDhGMZjXZxm3h0SFapvSKEz8WOw7QPpUgYQ== X-Received: by 2002:a17:906:5a6c:b0:77c:c2db:63ab with SMTP id my44-20020a1709065a6c00b0077cc2db63abmr5811423ejc.431.1663401584120; Sat, 17 Sep 2022 00:59:44 -0700 (PDT) Received: from localhost (vpn-konference.ms.mff.cuni.cz. [195.113.20.101]) by smtp.gmail.com with ESMTPSA id t11-20020a056402020b00b00452e7ae2214sm5828995edv.42.2022.09.17.00.59.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 17 Sep 2022 00:59:42 -0700 (PDT) Date: Sat, 17 Sep 2022 00:59:42 -0700 (PDT) X-Google-Original-Date: Sat, 17 Sep 2022 00:17:54 PDT (-0700) Subject: Re: [PATCH] riscv: implement TARGET_MODE_REP_EXTENDED In-Reply-To: <4d4edef0-8a44-d6b8-0f50-1abd7f5e91f4@gmail.com> From: Palmer Dabbelt To: gcc-patches@gcc.gnu.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,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 Fri, 16 Sep 2022 16:48:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote: > > 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. IMO the problem isn't so much that asm has this constraint, it's that it's a new constraint and thus risks breaking code that used to work. That said... > 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. Yes, and we have a few MIPS-isms in the ISA but don't have the same flavor of TRULY_NOOP_TRUNCATION. It's been pointed out a handful of times and I'm not sure what the right way to go is here, every time I try and reason about which is going to produce better code I come up with a different answer. IIRC last time I looked at this I came to the conclusion that we're doing the right thing for RISC-V because most of our instructions implicitly truncate. It's pretty easy to generate bad code here and I'm pretty sure we could fix some of that by moving to a more MIPS-like TRULY_MODE_TRUNCATION, but I think we'd end up just pushing the problems around. Every time I look at this I also get worried that we've leaked some of these internal promotion rules into something visible to inline asm, but when I poke around it seems like things generally work. > > > jeff