From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id E6E4E3858C2B for ; Fri, 4 Nov 2022 23:00:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E6E4E3858C2B 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-lj1-x234.google.com with SMTP id x21so8339313ljg.10 for ; Fri, 04 Nov 2022 16:00:16 -0700 (PDT) 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=es16pmtzgDHsMIs1LPnMIsKMg+z2Ffq8hDBQ5Vg6tY4=; b=sjX3MkrW/B/6/9eFlWdPgomQhxdy2k6pki3HJsGbh1Qxtq9dYFv8dESYdorppFvUGT SgMCBjKeaD1dGQ6Llg2FfdEfX+HlemiBBiS1gLAgQi4UcFkS8Zp5eEiSUg3mgSYs25KL K1YX4NIUFYw8vxkeprDPT3Hywp4Lx8mg7nK9midqxvb7VUaB78jrbMdkyhbVotxWRUrU fYDZLOhC9k+aRH9+IJHpt6IAPNl6FsQTUPruQoaucUxKsIcqR97W1EDsEphlzvNJq1xj 9jYlbzQIbdDAG91kkf2QLiiyQQPAafQNkWKunzAZhXypZC90fuqRvNlPuq9zNLtkQWNP MtEA== 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=es16pmtzgDHsMIs1LPnMIsKMg+z2Ffq8hDBQ5Vg6tY4=; b=mworRNEc7ABowGHQx46bHVhEzuZitj1xLfOBdMILm8NdQNVFJk8WRuEQQmr1HKb8js SUFWHQTQ/tdnjA7xOwlkkz9LnzwXmq48OW7jfn3F+aoBPSCG0h6kkc/meUprK87jMUhp Cw0Mu0gBPFTy6YjzkPLAhuCMpc0Vn3tXw+UPi1qDmDPctwmpjBBYdYH6lR+f09lh4q0j cUzOkvUtdkeWPYDWBnXgEstRacZg+SpKw973WHZHzB7AyQi+6NwiNQJsKCsW4gtPAReT R8poN+dVKjKyIbWHfK7+zO8X5+pWIP/al05Ukn0OW26SLsiVC6yprxiNJ0dKqQdc0XoD OYFA== X-Gm-Message-State: ACrzQf2j1ocM1qTDoMfl4d0vfE4YM2DUEkrEiHr3qc4oMsCcyE2pbhtK AzMc1mAzgwPAYqf6C3zgPqrrsIgMFBvjx8Qrbkj/0Q== X-Google-Smtp-Source: AMsMyM59e43/0opSNc9YTE8Q2te2ZL6jfn0nDaTzfmm4/igAO6WcNlRgej0WdGp9jrKRTNYGjq5Q6s/jWBtrxufCTUM= X-Received: by 2002:a2e:8781:0:b0:26d:e758:ce84 with SMTP id n1-20020a2e8781000000b0026de758ce84mr13702168lji.178.1667602815324; Fri, 04 Nov 2022 16:00:15 -0700 (PDT) MIME-Version: 1.0 References: <20220905214437.1275139-1-philipp.tomsich@vrull.eu> In-Reply-To: From: Philipp Tomsich Date: Sat, 5 Nov 2022 00:00:04 +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 Content-Type: multipart/alternative; boundary="0000000000006f317505ecad0953" X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,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: --0000000000006f317505ecad0953 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =3D=3D SImode && mode_rep =3D=3D 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 (... : "=3Dr" (a))" will take DI/SI/HI/QImode depending on the type of a. The concern, as far as I understand would be the case where the assembly-sequence leaves an incompatible extension in the register. So l understand the problem being: int a; asm volatile ("zext.w %0, %1" : "=3Dr"(a) : "r"(b)); // possible pitfa= ll -- the programmer wants a SImode representation (so it needs to be extended) but not long long a; asm volatile ("zext.w %0, %1" : "=3Dr"(a): "r"(b)); // possible pitfa= ll -- the programmer wants the DImode representation (don't extend) If we look at the output of expand for the first case (I made sure to consume "a" again using a "asm volatile ("nop" : : "r"(a))"), we see that an explicit extension is created from SImode to DImode (the "(subreg:SI (reg:DI ...) 0)" in the asm-operand for the next block is a bigger concern =E2=80=94 this may be an artifact of TARGET_TRULY_NOOP_TRUNCATION not being properly defined on RISC-V; but this issue didn't originate from this patch): ;; __asm__ __volatile__("zext.w %0,%1" : "=3Dr" a_2 : "r" b_1(D)); (insn 7 5 6 (set (reg:SI 75 [ aD.1490 ]) (asm_operands/v:SI ("zext.w %0,%1") ("=3Dr") 0 [ (reg/v:DI 74 [ bD.1487 ]) ] [ (asm_input:DI ("r") ./rep-asm.c:5) ] [] ./rep-asm.c:5)) "./rep-asm.c":5:3 -1 (nil)) (insn 6 7 0 (set (reg/v:DI 72 [ aD.1490 ]) (sign_extend:DI (reg:SI 75 [ aD.1490 ]))) "./rep-asm.c":5:3 -1 (nil)) ;; __asm__ __volatile__("nop" : : "r" a_2); (insn 8 6 0 (asm_operands/v ("nop") ("") 0 [ (subreg/s/u:SI (reg/v:DI 72 [ aD.1490 ]) 0) ] [ (asm_input:SI ("r") ./rep-asm.c:6) ] [] ./rep-asm.c:6) "./rep-asm.c":6:3 -1 (nil)) which translates to: f: #APP # 5 "./rep-asm.c" 1 zext.w a0,a0 # 0 "" 2 #NO_APP sext.w a0,a0 #APP # 6 "./rep-asm.c" 1 nop # 0 "" 2 #NO_APP If this patch is not applied (and TARGET_MODE_REP_EXTENDED is not defined), we see the sext.w missing. So in fact, we may have unintentionally fixed an issue? > 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. Good point. This should indeed be added and we'll look into this in more detail for v2. Looking into this in more detail, it seems that this change doesn't make things worse (we already had that problem before, as an explicit extension might also lead to the same reasoning). So somehow we've been avoiding this bullet so far, although I don't know yet how... Philipp. --0000000000006f317505ecad0953--