From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by sourceware.org (Postfix) with ESMTPS id E02323858D3C for ; Sun, 24 Dec 2023 08:11:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E02323858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gcc.gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E02323858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.215.175 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703405503; cv=none; b=Azv5Seo5P9iJ7vlrHS0NLxU1S/DSkBC27tHFR0mqwghNaIcbvCDf86vuJVzrSkvuXZYFUYgK2Vos8MJFE2vH9GiaZmKHAytlaIc1SsOtVE72N1rcm0P4+9dmDo1SQYNTXTcLSHK0eaDjbV0NKV1jbrRjSW1H0sAki6AsFa7dF78= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703405503; c=relaxed/simple; bh=4H1Cmp6TACG4HpydDDooZ74ShR4ifDt2mP4BdI3zLMs=; h=MIME-Version:From:Date:Message-ID:Subject:To; b=ivNLT6/JfD7BIyhpQ4psK0G/Gg7f+szGUMop4/KKRmZi3Sp2A8OvxW5QxdIH3s2jNimquz1PAFaEprN6VLjjleq5L1S3+vCPKqSgYl2eBkQO4esl8ubNFH4zZlo822gKeprzCz0fhQfCermZLHBMcPX+0FjghfIExmWJ9FDkgaw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pg1-f175.google.com with SMTP id 41be03b00d2f7-53fbf2c42bfso2278531a12.3 for ; Sun, 24 Dec 2023 00:11:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703405500; x=1704010300; 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=iB1Lj/GORcAGir6f38bg/o91iADAnu3ZvG/bcfZ/3c0=; b=tKn3oRxC+MKA9WfHDfk3w12/wLKSP8axTv9/Xqob9f1QibYqj3C/ZOUB4aB1F9sLXl WlU+YMiFrukzSnM7bLyy4xJl/YSs8vaP8bzANNV2nx2GvWH+R22+Sigwqwzag2ppW0Lf FyQ+CCQvo0kxWPiPQT8snEdM5iar8FIKTsp3VkOzWjVzlRc5V9BRWEmMFjIpuvDf3Tq9 EbPpesBqk3w4vDKIVz6zBR96wrs0L51ef/MVUq5iajfZnFtGciFmnqtDsBTMeuAJNNqw 4TWoInk6aFELqMbMWiXUOJ3hJ6qL/t3OoNqLkP4H37TVLzU/NqJe9Z+1S8cukfWaOa7e ToCw== X-Gm-Message-State: AOJu0YwE7CUq4M40mT0qAdvoRASP2QxGZsXT3lgXf8aQFXw1rqNCzSaH R6pHP4VFEHzol/8edZ0ukcVNjzDj0uQq5A== X-Google-Smtp-Source: AGHT+IFjLhc4xumGkxl8ynXVYS2xMYm+7BJW1HYtEZ3EUqWmoj3MglmQ2p/ixv3/cGcjRBX4HmUVTw== X-Received: by 2002:a05:6a20:3c89:b0:187:c3db:8999 with SMTP id b9-20020a056a203c8900b00187c3db8999mr4559380pzj.45.1703405499997; Sun, 24 Dec 2023 00:11:39 -0800 (PST) Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com. [209.85.216.47]) by smtp.gmail.com with ESMTPSA id ge16-20020a17090b0e1000b0028559a67729sm4934258pjb.42.2023.12.24.00.11.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 Dec 2023 00:11:39 -0800 (PST) Received: by mail-pj1-f47.google.com with SMTP id 98e67ed59e1d1-28b400f08a4so2394278a91.1 for ; Sun, 24 Dec 2023 00:11:39 -0800 (PST) X-Received: by 2002:a17:903:2349:b0:1cf:f7c3:1e32 with SMTP id c9-20020a170903234900b001cff7c31e32mr4258176plh.27.1703405499460; Sun, 24 Dec 2023 00:11:39 -0800 (PST) MIME-Version: 1.0 References: <20231223085858.4136369-1-syq@gcc.gnu.org> <04a01582-2bff-496f-95b1-4643b5a2f494@gmail.com> In-Reply-To: From: YunQiang Su Date: Sun, 24 Dec 2023 16:11:27 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] EXPR: Emit an truncate if 31+ bits polluted for SImode To: Jeff Law Cc: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com, pinskia@gmail.com, rguenther@suse.de Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: > > Yes. I also guess so. Any new idea? > Well, I see multiple intertwined issues and I think MIPS has largely > mucked this up. > > At a high level DI -> SI truncation is not a nop on MIPS64. We must > explicitly sign extend the value from SI->DI to preserve the invariant > that SI mode objects are extended to DImode. If we fail to do that, > then the SImode conditional branch patterns simply aren't going to work. > MIPS64 never claims DI -> SI is nop, instead it claims SI -> DI is nop. And for MIPS64, it has only one type of branch. it works for both SI and DI. MIPS64 has 3 groups of instructions: 1. The instructions from MIPS32, 32bit calculations included. These instructions expect the source values are properly sign-extended, otherwise, the result is UNPREDICTABLE. And they make sure that the Destinations are sign-extended. Let's use INS here as an example. 2. The newly added 64bit ops. Let's use DINS here as an example. 3. branch instructions They works depending on the value of the registers. > What doesn't make sense to me is that for truncation, the output mode is > going to be smaller than the input mode. Which makes logical sense and > is codified in the documentation: > > > @deftypefn {Target Hook} bool TARGET_TRULY_NOOP_TRUNCATION (poly_uint64 @var{outprec}, poly_uint64 @var{inprec}) > > This hook returns true if it is safe to ``convert'' a value of > > @var{inprec} bits to one of @var{outprec} bits (where @var{outprec} is > > smaller than @var{inprec}) by merely operating on it as if it had only > > @var{outprec} bits. The default returns true unconditionally, which > > is correct for most machines. When @code{TARGET_TRULY_NOOP_TRUNCATION} > > returns false, the machine description should provide a @code{trunc} > > optab to specify the RTL that performs the required truncation. > > > Yet the implementation in the mips backend: > > > static bool > > mips_truly_noop_truncation (poly_uint64 outprec, poly_uint64 inprec) > > { > > return !TARGET_64BIT || inprec <= 32 || outprec > 32; > > } > > > Can you verify what values are getting in here? If we're being called > with inprec as 32 and outprec as 64, we're going to return true which > makes absolutely no sense at all. > One of a key design rule of MIPS, is to reduce hardware mode switch as possible. Converting from 32 to 64 does be nop, IF the 32 is properly sign extended. Since the nature of the 1st group of instructions (the result is always sign extended) MIPS's software stack carefully keeps SI values sign-extended. So MIPS64 can claims SI -> DI is nop. With this design, supporting 32bit software on 64bit hardware is smoothly, without any mode switch etc. The only exception is here: the 64bit bitops pollute a SI mode hard register: lbu $3,3($4) dins $2,$3,24,8 bltz $2,.L2 LBU loads a value from memory. It's OK now. and DINS insert it to $2, and it will pollute bit 31, since DINS is a newly added MIPS64 instruction, it won't copy bit31 to bits[32:63]. It will make $2, now a malformed SI mode hard register (31-63 bit is not ALL same). Then BLTZ will believe it is a normal DI/64bit value. We have two options here to solve this problem: 1. Use INS instead of DINS. In the original C code, the variable `val` is a value with SI mode. So we should use INS here, as INS will to be sure the result is well sign-extended. That's what I tried with the previous patches: [V1] https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624174.html [V2] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626137.html 2. Add an truncate or sign_extent instruction just after the instruction, which may pollute the 31+bits of a SImode registers. That's what I am trying to do with this V3 patch. The result asm code will be like this: lbu $3,3($4) dins $2,$3,24,8 sll $2,$2,0 # <--- newly added instruction bltz $2,.L2 Background: SLL (shift left logical) is a special instruction in MIPS: 1. SLL rX,rY,0 on MIPS64 is 32bit sign-extend operation. 2. SLL r0,r0,0 is NOP instruction. 3. SLL r0,r0,1 is SSNOP (Superscalar No Operation) 4. SLL r0,r0,3 is EHB (Execution Hazard Barrier) > Jeff